draft-ietf-lisp-lcaf-21.txt   draft-ietf-lisp-lcaf-22.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: May 20, 2017 Brocade Expires: June 1, 2017 Brocade
J. Snijders J. Snijders
NTT Communications NTT
November 16, 2016 November 28, 2016
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-21 draft-ietf-lisp-lcaf-22
Abstract Abstract
This draft defines a canonical address format encoding used in LISP This document defines a canonical address format encoding used in
control messages and in the encoding of lookup keys for the LISP LISP control messages and in the encoding of lookup keys for the LISP
Mapping Database System. Mapping Database System.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2017. This Internet-Draft will expire on June 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5 3. LISP Canonical Address Format Encodings . . . . . . . . . . . 5
4. LISP Canonical Address Applications . . . . . . . . . . . . . 7 4. LISP Canonical Address Applications . . . . . . . . . . . . . 8
4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 8
4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 9
4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 10 4.3. Assigning Geo Coordinates to Locator Addresses . . . . . 11
4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 12 4.4. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13
4.5. Multicast Group Membership Information . . . . . . . . . 14 4.5. Multicast Group Membership Information . . . . . . . . . 15
4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 16 4.6. Traffic Engineering using Re-encapsulating Tunnels . . . 17
4.7. Storing Security Data in the Mapping Database . . . . . . 17 4.7. Storing Security Data in the Mapping Database . . . . . . 18
4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 19 4.8. Source/Destination 2-Tuple Lookups . . . . . . . . . . . 20
4.9. Replication List Entries for Multicast Forwarding . . . . 21 4.9. Replication List Entries for Multicast Forwarding . . . . 22
4.10. Applications for AFI List Type . . . . . . . . . . . . . 22 4.10. Applications for AFI List Type . . . . . . . . . . . . . 23
4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 22 4.10.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . 23
4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.10.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 24
4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 25
4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.4. Using Recursive LISP Canonical Address Encodings . . 26
4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 27
5. Experimental LISP Canonical Address Applications . . . . . . 27 5. Experimental LISP Canonical Address Applications . . . . . . 28
5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 29
5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 29 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 30
5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.3. PETR Admission Control Functionality . . . . . . . . . . 32
5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 33
5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 34
5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . 39
8.2. Informative References . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 42
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 42
B.1. Changes to draft-ietf-lisp-lcaf-21.txt . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-22.txt . . . . . . . . . 42
B.2. Changes to draft-ietf-lisp-lcaf-20.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-21.txt . . . . . . . . . 43
B.3. Changes to draft-ietf-lisp-lcaf-19.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-20.txt . . . . . . . . . 43
B.4. Changes to draft-ietf-lisp-lcaf-18.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-19.txt . . . . . . . . . 43
B.5. Changes to draft-ietf-lisp-lcaf-17.txt . . . . . . . . . 41 B.5. Changes to draft-ietf-lisp-lcaf-18.txt . . . . . . . . . 43
B.6. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . 41 B.6. Changes to draft-ietf-lisp-lcaf-17.txt . . . . . . . . . 43
B.7. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . 43
B.8. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 44
B.9. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 44
B.10. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 44
B.11. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 42 B.11. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 44
B.12. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 44
B.13. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 44
B.14. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 45
B.15. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 45
B.16. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 45
B.17. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 43 B.17. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 45
B.18. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 45
B.19. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 43 B.19. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 45
B.20. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 43 B.20. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 46
B.21. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 43 B.21. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 46
B.22. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 44 B.22. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 B.23. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
The LISP architecture and protocols [RFC6830] introduces two new The LISP architecture and protocols [RFC6830] introduces two new
numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
(RLOCs). To provide flexibility for current and future applications, (RLOCs). To provide flexibility for current and future applications,
these values can be encoded in LISP control messages using a general these values can be encoded in LISP control messages using a general
syntax that includes Address Family Identifier (AFI), length, and syntax that includes Address Family Identifier (AFI), length, and
value fields. value fields.
Currently defined AFIs include IPv4 and IPv6 addresses, which are Currently defined AFIs include IPv4 and IPv6 addresses, which are
formatted according to code-points assigned in [AFI] as follows: formatted according to code-points assigned in [AFI] as follows:
Specific detail uses for the LCAF types defined in this document can
be found in the use-case documents that use them. There may be more
than one use-case document that use the same LCAF type.
IPv4 Encoded Address: IPv4 Encoded Address:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 1 | IPv4 Address ... | | AFI = 1 | IPv4 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address | | ... IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Encoded Address: IPv6 Encoded Address:
skipping to change at page 4, line 25 skipping to change at page 4, line 25
| ... IPv6 Address ... | | ... IPv6 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address | | ... IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document describes the currently-defined AFIs the LISP protocol This document describes the currently-defined AFIs the LISP protocol
uses along with their encodings and introduces the LISP Canonical uses along with their encodings and introduces the LISP Canonical
Address Format (LCAF) that can be used to define the LISP-specific Address Format (LCAF) that can be used to define the LISP-specific
encodings for arbitrary AFI values. encodings for arbitrary AFI values.
Specific detail uses for the LCAF types defined in this document can
be found in the use-case documents that use them. The same LCAF type
may be used by more than one use-case document. As an experimental
specification, this work is by definition, incomplete. The LCAF
types defined in this document are to support experimentation and
intended for cautious use in self-contained environments in support
of the corresponding use-case documents. This document provides
assignment for an initial set of approved LCAF Types (registered with
IANA) and additional unapproved LCAF Types [RFC6830]. The unapproved
LCAF encodings are defined to support further study and
experimentation.
2. Definition of Terms 2. Definition of Terms
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. Address families are defined for IPv4 and encoding in a packet. Address families are defined for IPv4 and
IPv6. See [AFI] and [RFC3232] for details. The reserved AFI IPv6. See [AFI] and [RFC3232] for details. The reserved AFI
value of 0 is used in this specification to indicate an value of 0 is used in this specification to indicate an
unspecified encoded address where the length of the address is 0 unspecified encoded address where the length of the address is 0
bytes following the 16-bit AFI value of 0. bytes following the 16-bit AFI value of 0.
Unspecified Address Format: Unspecified Address Format:
skipping to change at page 5, line 52 skipping to change at page 6, line 25
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd1/Rsvd2: these 8-bit fields are reserved for future use and MUST Rsvd1/Rsvd2: these 8-bit fields are reserved for future use and MUST
be transmitted as 0 and ignored on receipt. be transmitted as 0 and ignored on receipt.
Flags: this 8-bit field is for future definition and use. For now, Flags: this 8-bit field is for future definition and use. For now,
set to zero on transmission and ignored on receipt. set to zero on transmission and ignored on receipt.
Type: this 8-bit field is specific to the LISP Canonical Address Type: this 8-bit field is specific to the LISP Canonical Address
formatted encodings. Currently allocated values are: formatted encodings. Currently allocated (both approved and
unapproved) values are:
Type 0: Null Body Type Type 0: Null Body Type
Type 1: AFI List Type Type 1: AFI List Type
Type 2: Instance ID Type Type 2: Instance ID Type
Type 3: AS Number Type Type 3: AS Number Type
Type 4: Application Data Type Type 4: Application Data Type
skipping to change at page 6, line 49 skipping to change at page 7, line 22
Length: this 16-bit field is in units of bytes and covers all of the Length: this 16-bit field is in units of bytes and covers all of the
LISP Canonical Address payload, starting and including the byte LISP Canonical Address payload, starting and including the byte
after the Length field. When including the AFI, an LCAF encoded after the Length field. When including the AFI, an LCAF encoded
address will have a minimum length of 8 bytes when the Length address will have a minimum length of 8 bytes when the Length
field is 0. The 8 bytes include the AFI, Flags, Type, Rsvd1, field is 0. The 8 bytes include the AFI, Flags, Type, Rsvd1,
Rsvd2, and Length fields. When the AFI is not next to an encoded Rsvd2, and Length fields. When the AFI is not next to an encoded
address in a control message, then the encoded address will have a address in a control message, then the encoded address will have a
minimum length of 6 bytes when the Length field is 0. The 6 bytes minimum length of 6 bytes when the Length field is 0. The 6 bytes
include the Flags, Type, Rsvd1, Rsvd2, and Length fields. include the Flags, Type, Rsvd1, Rsvd2, and Length fields.
[RFC6830] states RLOC records are sorted when encoded in control [RFC6830] states RLOC records based on an IP address are sorted when
messages so the locator-set has consistent order across all xTRs for encoded in control messages so the locator-set has consistent order
a given EID. The sort order is based on sort-key {afi, RLOC- across all xTRs for a given EID. The sort order is based on sort-key
address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- {afi, RLOC-address}. When an RLOC based on an IP address is LCAF
Type}. Therefore, when a locator-set has a mix of AFI records and encoded, the sort-key is {afi, LCAF-Type}. Therefore, when a locator-
LCAF records, they are ordered from smallest to largest AFI value. set has a mix of AFI records and LCAF records, they are ordered from
smallest to largest AFI value.
4. LISP Canonical Address Applications 4. LISP Canonical Address Applications
The following sections define the LCAF for the currently approved
initial set of Type values.
4.1. Segmentation using LISP 4.1. Segmentation using LISP
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-prefixes, their address spaces must remain addresses [RFC1918] as EID-prefixes, their address spaces must remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI-based address the address encoding can aid in making the entire AFI-based address
unique. unique.
Another use for the Instance ID LISP Canonical Address Format is when Another use for the Instance ID LISP Canonical Address Format is when
creating multiple segmented VPNs inside of a LISP site where keeping creating multiple segmented VPNs inside of a LISP site where keeping
skipping to change at page 12, line 5 skipping to change at page 12, line 22
The Geo Coordinates Canonical Address Type can be used to encode The Geo Coordinates Canonical Address Type can be used to encode
either EID or RLOC addresses. When used for EID encodings, you can either EID or RLOC addresses. When used for EID encodings, you can
determine the physical location of an EID along with the topological determine the physical location of an EID along with the topological
location by observing the locator-set. location by observing the locator-set.
Usage: This encoding can be used in EID or RLOC records in Map- Usage: This encoding can be used in EID or RLOC records in Map-
Requests, Map-Replies, Map-Registers, and Map-Notify messages. When Requests, Map-Replies, Map-Registers, and Map-Notify messages. When
LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system mechanism,
extended EIDs are used in Map-Referral messages. extended EIDs are used in Map-Referral messages.
The use of the Geo-Coordinates LCAF encoding raises privacy issues as
location information is privacy sensitive, and possibly unexpectedly
privacy sensitive information may be conveyed, e.g. if the location
information corresponds to a router located in a person's home.
Therefore, this encoding should not be used unless needed for
operation of a LISP deployment. Before electing to utilize this
encoding, care should be taken to ensure the appropriate policies are
being used by the EID for controlling the conveyed information.
4.4. NAT Traversal Scenarios 4.4. NAT Traversal Scenarios
When a LISP system is conveying global address and mapped port When a LISP system is conveying global address and mapped port
information when traversing through a NAT device, the NAT-Traversal information when traversing through a NAT device, the NAT-Traversal
LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details. LCAF Type is used. See [I-D.ermagan-lisp-nat-traversal] for details.
NAT-Traversal Canonical Address Format: NAT-Traversal Canonical Address Format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 14, line 5 skipping to change at page 14, line 25
determined by parsing each field. When there are no RTRs determined by parsing each field. When there are no RTRs
supplied, the RTR fields can be omitted and reflected by the LCAF supplied, the RTR fields can be omitted and reflected by the LCAF
length field or an AFI of 0 can be used to indicate zero RTRs length field or an AFI of 0 can be used to indicate zero RTRs
encoded. encoded.
Usage: This encoding can be used in Info-Request and Info-Reply Usage: This encoding can be used in Info-Request and Info-Reply
messages. The mapping system does not store this information. The messages. The mapping system does not store this information. The
information is used by an xTR and Map-Server to convey private and information is used by an xTR and Map-Server to convey private and
public address information when traversing NAT and firewall devices. public address information when traversing NAT and firewall devices.
Care should be taken to protect privacy against the adverse use of a
Global or Private ETR RLOC Address by ensuring policy controls are
used during EID registrations that use this LCAF Type in RLOC-
records. Refer to the use case documents for additional information.
4.5. Multicast Group Membership Information 4.5. Multicast Group Membership Information
Multicast group information can be published in the mapping database. Multicast group information can be published in the mapping database.
So a lookup on a group address EID can return a replication list of So a lookup on a group address EID can return a replication list of
RLOC group addresses or RLOC unicast addresses. The intent of this RLOC group addresses or RLOC unicast addresses. The intent of this
type of unicast replication is to deliver packets to multiple ETRs at type of unicast replication is to deliver packets to multiple ETRs at
receiver LISP multicast sites. The locator-set encoding for this EID receiver LISP multicast sites. The locator-set encoding for this EID
record type can be a list of ETRs when they each register with "Merge record type can be a list of ETRs when they each register with "Merge
Semantics". The encoding can be a typical AFI-encoded locator Semantics". The encoding can be a typical AFI-encoded locator
address. When an RTR list is being registered (with multiple levels address. When an RTR list is being registered (with multiple levels
skipping to change at page 23, line 33 skipping to change at page 24, line 33
Length: length in bytes starting and including the byte after this Length: length in bytes starting and including the byte after this
Length field. Length field.
This address format can be used to connect layer-2 domains together This address format can be used to connect layer-2 domains together
using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN. using LISP over an IPv4 or IPv6 core network to create a layer-2 VPN.
In this use case, a MAC address is being used as an EID, and the In this use case, a MAC address is being used as an EID, and the
locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or locator-set that this EID maps to can be an IPv4 or IPv6 RLOCs, or
even another MAC address being used as an RLOC. See even another MAC address being used as an RLOC. See
[I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when [I-D.portoles-lisp-eid-mobility] for how layer-2 VPNs operate when
doing EID mobility. Refer to the Security Considerations section for doing EID mobility.
privacy protection.
Care should be taken to protect privacy against the adverse use of a
Layer-2 MAC Address by ensuring policy controls are used during EID
registrations that use AFI=6 encodings in RLOC-records. Refer to the
use case documents for additional information.
4.10.3. ASCII Names in the Mapping Database 4.10.3. ASCII Names in the Mapping Database
If DNS names [RFC1035] or URIs [RFC3986] are stored in the LISP If DNS names [RFC1035] or URIs [RFC3986] are stored in the LISP
Mapping Database System, the AFI List Type can be used to carry an Mapping Database System, the AFI List Type can be used to carry an
ASCII string. ASCII string.
ASCII LISP Canonical Address Format: ASCII LISP Canonical Address Format:
0 1 2 3 0 1 2 3
skipping to change at page 27, line 12 skipping to change at page 28, line 12
A LISP system is required to support the AFI List LCAF Type to use A LISP system is required to support the AFI List LCAF Type to use
this procedure. It would skip over 10 bytes of the Geo Coordinate this procedure. It would skip over 10 bytes of the Geo Coordinate
LCAF Type to get to the locator address encoding (an IPv4 locator LCAF Type to get to the locator address encoding (an IPv4 locator
address). A LISP system that does support the Geo Coordinate LCAF address). A LISP system that does support the Geo Coordinate LCAF
Type can support parsing the locator address within the Geo Type can support parsing the locator address within the Geo
Coordinate LCAF encoding or in the locator encoding that follows in Coordinate LCAF encoding or in the locator encoding that follows in
the AFI List LCAF. the AFI List LCAF.
5. Experimental LISP Canonical Address Applications 5. Experimental LISP Canonical Address Applications
The following sections describe experimental LCAF encodings. These
LCAF Types are not approved (registered with IANA). The inclusion of
these encodings in this document are in support of further study and
experimentation to determine whether these encodings are functional,
if there is a demand for these use cases, and better understand
deployment considerations. As noted previously, these LCAF Types are
restricted to cautious use in self-contained environments in support
of the corresponding use-case documents.
5.1. Convey Application Specific Data 5.1. Convey Application Specific Data
When a locator-set needs to be conveyed based on the type of When a locator-set needs to be conveyed based on the type of
application or the Per-Hop Behavior (PHB) of a packet, the application or the Per-Hop Behavior (PHB) of a packet, the
Application Data Type can be used. Application Data Type can be used.
Application Data LISP Canonical Address Format: Application Data LISP Canonical Address Format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 35, line 10 skipping to change at page 37, line 10
U: The RLOCs listed in the AFI-encoded addresses in the next longword U: The RLOCs listed in the AFI-encoded addresses in the next longword
can accept GUE encapsulation using destination UDP port TBD can accept GUE encapsulation using destination UDP port TBD
[I-D.herbert-gue]. [I-D.herbert-gue].
Usage: This encoding can be used in RLOC records in Map-Requests, Usage: This encoding can be used in RLOC records in Map-Requests,
Map-Replies, Map-Registers, and Map-Notify messages. Map-Replies, Map-Registers, and Map-Notify messages.
6. Security Considerations 6. Security Considerations
There are no security considerations for this specification. The This document is classified as Experimental. The LCAF encodings
security considerations are documented for the protocols that use defined in this document are intended to be used with their
LISP Canonical Addressing. corresponding use cases and in self-contained environments. Users
should carefully consider how the [I-D.ietf-lisp-sec] threat model
applies to their particular use case.
The use of the Geo-Coordinates LCAF Type may raise physical privacy The use of the Geo-Coordinates LCAF Type may raise physical privacy
issues. Care should be taken when configuring the mapping system to issues. Care should be taken when configuring the mapping system to
use specific policy parameters so geo-location information is not use specific policy parameters so geo-location information is not
returned gratuitously. It is recommended that any documents that returned gratuitously. It is recommended that any documents that
specify the use of the Geo-Coordinates LCAF Type should consider the specify the use of the Geo-Coordinates LCAF Type should consider the
applicability of the BCP160 [RFC6280] for location-based privacy applicability of the BCP160 [RFC6280] for location-based privacy
protection. protection.
Additional privacy concerns have arisen since publication of BCP160,
and future work on LISP should examine potential threats beyond
BCP160 and address improving privacy and security for LISP
deployments.
7. IANA Considerations 7. IANA Considerations
This document defines a canonical address format encoding used in This document defines a canonical address format encoding used in
LISP control messages and in the encoding of lookup keys for the LISP LISP control messages and in the encoding of lookup keys for the LISP
Mapping Database System. Such address format is based on a fixed AFI Mapping Database System. Such address format is based on a fixed AFI
(16387) and a LISP LCAF Type field. (16387) and a LISP LCAF Type field.
The LISP LCAF Type field is an 8-bit field specific to the LISP The LISP LCAF Type field is an 8-bit field specific to the LISP
Canonical Address formatted encodings, for which IANA is to create Canonical Address formatted encodings, for which IANA is to create
and maintain a new registry (as outlined in [RFC5226]) entitled "LISP and maintain a new registry (as outlined in [RFC5226]) entitled "LISP
LCAF Type". Initial values for the LISP LCAF Type registry are given LCAF Type". Initial values for the LISP LCAF Type registry are given
below. Future assignments are to be made through expert review with below. Future assignments are to be made based on specification
a specification required publication. Assignments consist of a LISP required. Assignments consist of a LISP LCAF Type name and its
LCAF Type name and its associated value: associated value:
+-------+------------------------------+------------+ +-------+------------------------------+------------+
| Value | LISP LCAF Type Name | Definition | | Value | LISP LCAF Type Name | Definition |
+-------+------------------------------+------------+ +-------+------------------------------+------------+
| 0 | Null Body Type | Section 3 | | 0 | Null Body Type | Section 3 |
| 1 | AFI List Type | Section 3 | | 1 | AFI List Type | Section 3 |
| 2 | Instance ID Type | Section 3 | | 2 | Instance ID Type | Section 3 |
| 3 | AS Number Type | Section 3 | | 3 | AS Number Type | Section 3 |
| 5 | Geo Coordinates Type | Section 3 | | 5 | Geo Coordinates Type | Section 3 |
| 7 | NAT-Traversal Type | Section 3 | | 7 | NAT-Traversal Type | Section 3 |
skipping to change at page 39, line 15 skipping to change at page 41, line 20
[I-D.ietf-lisp-crypto] [I-D.ietf-lisp-crypto]
Farinacci, D. and B. Weis, "LISP Data-Plane Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", draft-ietf-lisp-crypto-10 (work in Confidentiality", draft-ietf-lisp-crypto-10 (work in
progress), October 2016. progress), October 2016.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-08 (work in progress), September 2016. ddt-08 (work in progress), September 2016.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), November 2016.
[I-D.portoles-lisp-eid-mobility] [I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid- Unified Control Plane", draft-portoles-lisp-eid-
mobility-01 (work in progress), October 2016. mobility-01 (work in progress), October 2016.
[I-D.quinn-vxlan-gpe] [I-D.quinn-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol Extension for VXLAN",
skipping to change at page 40, line 19 skipping to change at page 42, line 32
The authors would like to thank Albert Cabellos-Aparicio and Florin The authors would like to thank Albert Cabellos-Aparicio and Florin
Coras for discussions that lead to the definition of the Replication Coras for discussions that lead to the definition of the Replication
List Entry LCAF type. List Entry LCAF type.
Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for Thanks goes to Michiel Blokzijl and Alberto Rodriguez-Natal for
suggesting new LCAF types. suggesting new LCAF types.
Thanks also goes to Terry Manderson for assistance obtaining a LISP Thanks also goes to Terry Manderson for assistance obtaining a LISP
AFI value from IANA. AFI value from IANA.
And finally, the authors thank Stephen Farrell (Security Area
Director) and Deborah Brungard (Routing Area Director) for their
suggested text to get the document through IESG review.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-lcaf-21.txt B.1. Changes to draft-ietf-lisp-lcaf-22.txt
o Submitted November 2016.
o Take into account RTG area director Deborah Brungard's comments
suggestions.
o The changes put in shoudl clear Stephen's DISCUSS comments on
RLOC-record ordering and privacy concerns with the Geo-Coordinate
LCAF type.
B.2. Changes to draft-ietf-lisp-lcaf-21.txt
o Submitted November 2016. o Submitted November 2016.
o Reflect Alexey's DISCUSS comments. o Reflect Alexey's DISCUSS comments.
o Add text to intro section that says the details for any LCAF type o Add text to intro section that says the details for any LCAF type
can be found in other use-case documents. can be found in other use-case documents.
o Provide general examples for JSON and DNS LCAF types. o Provide general examples for JSON and DNS LCAF types.
B.2. Changes to draft-ietf-lisp-lcaf-20.txt B.3. Changes to draft-ietf-lisp-lcaf-20.txt
o Submitted October 2016. o Submitted October 2016.
o Put in references to DNS names and URIs per Alexey's comment. o Put in references to DNS names and URIs per Alexey's comment.
B.3. Changes to draft-ietf-lisp-lcaf-19.txt B.4. Changes to draft-ietf-lisp-lcaf-19.txt
o Submitted October 2016. o Submitted October 2016.
o Make it more clear that any use-case documents that use the Geo- o Make it more clear that any use-case documents that use the Geo-
Coordinates LCAF type should discuss RFC6280 compliance. Coordinates LCAF type should discuss RFC6280 compliance.
B.4. Changes to draft-ietf-lisp-lcaf-18.txt B.5. Changes to draft-ietf-lisp-lcaf-18.txt
o Submitted October 2016 after October 13th telechat. o Submitted October 2016 after October 13th telechat.
o Addressed comments from Ben Campbell, Jari Arrko, Stephen Farrel, o Addressed comments from Ben Campbell, Jari Arrko, Stephen Farrel,
Peter Yee, Dale Worley, Mirja Kuehlewind, and Suresh Krishnan. Peter Yee, Dale Worley, Mirja Kuehlewind, and Suresh Krishnan.
B.5. Changes to draft-ietf-lisp-lcaf-17.txt B.6. Changes to draft-ietf-lisp-lcaf-17.txt
o Submitted October 2016. o Submitted October 2016.
o Addressed comments from Gen-ART reviewer Peter Yee. o Addressed comments from Gen-ART reviewer Peter Yee.
o Addressed IESG last-call comments from Suresh Krishnan. o Addressed IESG last-call comments from Suresh Krishnan.
B.6. Changes to draft-ietf-lisp-lcaf-16.txt B.7. Changes to draft-ietf-lisp-lcaf-16.txt
o Submitted October 2016. o Submitted October 2016.
o Addressed comments from Security Directorate reviewer David o Addressed comments from Security Directorate reviewer David
Mandelberg. Mandelberg.
B.7. Changes to draft-ietf-lisp-lcaf-15.txt B.8. Changes to draft-ietf-lisp-lcaf-15.txt
o Submitted September 2016. o Submitted September 2016.
o Addressed comments from Routing Directorate reviewer Stig Venass. o Addressed comments from Routing Directorate reviewer Stig Venass.
B.8. Changes to draft-ietf-lisp-lcaf-14.txt B.9. Changes to draft-ietf-lisp-lcaf-14.txt
o Submitted July 2016. o Submitted July 2016.
o Fix IDnits errors and comments from Luigi Iannone, document o Fix IDnits errors and comments from Luigi Iannone, document
shepherd. shepherd.
B.9. Changes to draft-ietf-lisp-lcaf-13.txt B.10. Changes to draft-ietf-lisp-lcaf-13.txt
o Submitted May 2016. o Submitted May 2016.
o Explain the Instance-ID LCAF Type is 32-bits in length and the o Explain the Instance-ID LCAF Type is 32-bits in length and the
Instance-ID field in the LISP encapsulation header is 24-bits. Instance-ID field in the LISP encapsulation header is 24-bits.
B.10. Changes to draft-ietf-lisp-lcaf-12.txt B.11. Changes to draft-ietf-lisp-lcaf-12.txt
o Submitted March 2016. o Submitted March 2016.
o Updated references and document timer. o Updated references and document timer.
o Removed the R, J, and L bits from the Multicast Info Type LCAF o Removed the R, J, and L bits from the Multicast Info Type LCAF
since working group decided to not go forward with draft- since working group decided to not go forward with draft-
farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp- farinacci-lisp-mr-signaling-03.txt in favor of draft- ietf-lisp-
signal-free-00.txt. signal-free-00.txt.
B.11. Changes to draft-ietf-lisp-lcaf-11.txt B.12. Changes to draft-ietf-lisp-lcaf-11.txt
o Submitted September 2015. o Submitted September 2015.
o Reflecting comments from Prague LISP working group. o Reflecting comments from Prague LISP working group.
o Readying document for a LISP LCAF registry, RFC publication, and o Readying document for a LISP LCAF registry, RFC publication, and
for new use cases that will be defined in the new charter. for new use cases that will be defined in the new charter.
B.12. Changes to draft-ietf-lisp-lcaf-10.txt B.13. Changes to draft-ietf-lisp-lcaf-10.txt
o Submitted June 2015. o Submitted June 2015.
o Fix coauthor Job's contact information. o Fix coauthor Job's contact information.
B.13. Changes to draft-ietf-lisp-lcaf-09.txt B.14. Changes to draft-ietf-lisp-lcaf-09.txt
o Submitted June 2015. o Submitted June 2015.
o Fix IANA Considerations section to request a registry to allocate o Fix IANA Considerations section to request a registry to allocate
and track LCAF Type values. and track LCAF Type values.
B.14. Changes to draft-ietf-lisp-lcaf-08.txt B.15. Changes to draft-ietf-lisp-lcaf-08.txt
o Submitted April 2015. o Submitted April 2015.
o Comment from Florin. The Application Data Type length field has a o Comment from Florin. The Application Data Type length field has a
typo. The field should be labeled "12 + n" and not "8 + n". typo. The field should be labeled "12 + n" and not "8 + n".
o Fix length fields in the sections titled "Using Recursive LISP o Fix length fields in the sections titled "Using Recursive LISP
Canonical Address Encodings", "Generic Database Mapping Lookups", Canonical Address Encodings", "Generic Database Mapping Lookups",
and "Data Model Encoding". and "Data Model Encoding".
B.15. Changes to draft-ietf-lisp-lcaf-07.txt B.16. Changes to draft-ietf-lisp-lcaf-07.txt
o Submitted December 2014. o Submitted December 2014.
o Add a new LCAF Type called "Encapsulation Format" so decapsulating o Add a new LCAF Type called "Encapsulation Format" so decapsulating
xTRs can inform encapsulating xTRs what data-plane encapsulations xTRs can inform encapsulating xTRs what data-plane encapsulations
they support. they support.
B.16. Changes to draft-ietf-lisp-lcaf-06.txt B.17. Changes to draft-ietf-lisp-lcaf-06.txt
o Submitted October 2014. o Submitted October 2014.
o Make it clear how sorted RLOC records are done when LCAFs are used o Make it clear how sorted RLOC records are done when LCAFs are used
as the RLOC record. as the RLOC record.
B.17. Changes to draft-ietf-lisp-lcaf-05.txt B.18. Changes to draft-ietf-lisp-lcaf-05.txt
o Submitted May 2014. o Submitted May 2014.
o Add a length field of the JSON payload that can be used for either o Add a length field of the JSON payload that can be used for either
binary or text encoding of JSON data. binary or text encoding of JSON data.
B.18. Changes to draft-ietf-lisp-lcaf-04.txt B.19. Changes to draft-ietf-lisp-lcaf-04.txt
o Submitted January 2014. o Submitted January 2014.
o Agreement among ELP implementors to have the AFI 16-bit field o Agreement among ELP implementors to have the AFI 16-bit field
adjacent to the address. This will make the encoding consistent adjacent to the address. This will make the encoding consistent
with all other LCAF type address encodings. with all other LCAF type address encodings.
B.19. Changes to draft-ietf-lisp-lcaf-03.txt B.20. Changes to draft-ietf-lisp-lcaf-03.txt
o Submitted September 2013. o Submitted September 2013.
o Updated references and author's affilations. o Updated references and author's affilations.
o Added Instance-ID to the Multicast Info Type so there is relative o Added Instance-ID to the Multicast Info Type so there is relative
ease in parsing (S,G) entries within a VPN. ease in parsing (S,G) entries within a VPN.
o Add port range encodings to the Application Data LCAF Type. o Add port range encodings to the Application Data LCAF Type.
o Add a new JSON LCAF Type. o Add a new JSON LCAF Type.
o Add Address Key/Value LCAF Type to allow attributes to be attached o Add Address Key/Value LCAF Type to allow attributes to be attached
to an address. to an address.
B.20. Changes to draft-ietf-lisp-lcaf-02.txt B.21. Changes to draft-ietf-lisp-lcaf-02.txt
o Submitted March 2013. o Submitted March 2013.
o Added new LCAF Type "Replication List Entry" to support LISP o Added new LCAF Type "Replication List Entry" to support LISP
replication engineering use cases. replication engineering use cases.
o Changed references to new LISP RFCs. o Changed references to new LISP RFCs.
B.21. Changes to draft-ietf-lisp-lcaf-01.txt B.22. Changes to draft-ietf-lisp-lcaf-01.txt
o Submitted January 2013. o Submitted January 2013.
o Change longitude range from 0-90 to 0-180 in section 4.4. o Change longitude range from 0-90 to 0-180 in section 4.4.
o Added reference to WGS-84 in section 4.4. o Added reference to WGS-84 in section 4.4.
B.22. Changes to draft-ietf-lisp-lcaf-00.txt B.23. Changes to draft-ietf-lisp-lcaf-00.txt
o Posted first working group draft August 2012. o Posted first working group draft August 2012.
o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt. o This draft was renamed from draft-farinacci-lisp-lcaf-10.txt.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA San Jose, CA
skipping to change at page 44, line 31 skipping to change at page 47, line 15
Brocade Brocade
San Jose, CA San Jose, CA
USA USA
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
Job Snijders Job Snijders
NTT Communications NTT Communications
Theodorus Majofskistraat 100 Theodorus Majofskistraat 100
Amsterdam 1065 SZ Amsterdam 1065 SZ
NL The Netherlands
Email: job@ntt.net Email: job@ntt.net
 End of changes. 44 change blocks. 
101 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/