draft-ietf-lisp-lcaf-02.txt   draft-ietf-lisp-lcaf-03.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft lispers.net
Intended status: Experimental cisco Systems Intended status: Experimental D. Meyer
Expires: September 11, 2013 J. Snijders Expires: March 20, 2014 Brocade
InTouch N.V. J. Snijders
March 10, 2013 Hibernia Networks
September 16, 2013
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-02 draft-ietf-lisp-lcaf-03
Abstract Abstract
This draft defines a canonical address format encoding used in LISP This draft defines a canonical address format encoding used in LISP
control messages and in the encoding of lookup keys for the LISP control messages and in the encoding of lookup keys for the LISP
Mapping Database System. Mapping Database System.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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 September 11, 2013. This Internet-Draft will expire on March 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 23 skipping to change at page 2, line 24
4.3. Convey Application Specific Data . . . . . . . . . . . . . 9 4.3. Convey Application Specific Data . . . . . . . . . . . . . 9
4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10 4.4. Assigning Geo Coordinates to Locator Addresses . . . . . . 10
4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 12 4.5. Generic Database Mapping Lookups . . . . . . . . . . . . . 12
4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13 4.6. NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 13
4.7. PETR Admission Control Functionality . . . . . . . . . . . 15 4.7. PETR Admission Control Functionality . . . . . . . . . . . 15
4.8. Multicast Group Membership Information . . . . . . . . . . 16 4.8. Multicast Group Membership Information . . . . . . . . . . 16
4.9. Traffic Engineering using Re-encapsulating Tunnels . . . . 18 4.9. Traffic Engineering using Re-encapsulating Tunnels . . . . 18
4.10. Storing Security Data in the Mapping Database . . . . . . 19 4.10. Storing Security Data in the Mapping Database . . . . . . 19
4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20 4.11. Source/Destination 2-Tuple Lookups . . . . . . . . . . . . 20
4.12. Replication List Entries for Multicast Forwarding . . . . 21 4.12. Replication List Entries for Multicast Forwarding . . . . 21
4.13. Applications for AFI List Type . . . . . . . . . . . . . . 22 4.13. Data Model Encoding . . . . . . . . . . . . . . . . . . . 22
4.13.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 22 4.14. Encoding Key/Value Address Pairs . . . . . . . . . . . . . 23
4.13.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23 4.15. Applications for AFI List Type . . . . . . . . . . . . . . 23
4.13.3. ASCII Names in the Mapping Database . . . . . . . . . 23 4.15.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 23
4.13.4. Using Recursive LISP Canonical Address Encodings . . 24 4.15.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 25
4.13.5. Compatibility Mode Use Case . . . . . . . . . . . . . 25 4.15.3. ASCII Names in the Mapping Database . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 4.15.4. Using Recursive LISP Canonical Address Encodings . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 4.15.5. Compatibility Mode Use Case . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 31 7.2. Informative References . . . . . . . . . . . . . . . . . . 30
B.1. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 31 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 32
B.2. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 31 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 33
B.3. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 31 B.1. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 B.2. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 33
B.3. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 33
B.4. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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) which are intended to replace most use of IP addresses on the (RLOCs) which are intended to replace most use of IP addresses on the
Internet. To provide flexibility for current and future Internet. To provide flexibility for current and future
applications, these values can be encoded in LISP control messages applications, these values can be encoded in LISP control messages
using a general syntax that includes Address Family Identifier (AFI), using a general syntax that includes Address Family Identifier (AFI),
length, and value fields. length, and value fields.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Type 9: Multicast Info Type Type 9: Multicast Info Type
Type 10: Explicit Locator Path Type Type 10: Explicit Locator Path Type
Type 11: Security Key Type Type 11: Security Key Type
Type 12: Source/Dest Key Type Type 12: Source/Dest Key Type
Type 13: Replication List Entry Type Type 13: Replication List Entry Type
Type 14: JSON Data Model Type
Type 15: Key/Value Address Pair Type
Rsvd2: this 8-bit field is reserved for future use and MUST be Rsvd2: this 8-bit field is reserved for future use and MUST be
transmitted as 0 and ignored on receipt. transmitted as 0 and ignored on receipt.
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. So any LCAF encoded address will have a after the Length field. So any LCAF encoded address will have a
minimum length of 8 bytes when the Length field is 0. The 8 bytes minimum length of 8 bytes when the Length field is 0. The 8 bytes
include the AFI, Flags, Type, Reserved, and Length fields. When include the AFI, Flags, Type, Reserved, and Length fields. When
the AFI is not next to encoded address in a control message, then the AFI is not next to encoded address in a control message, then
the encoded address will have a minimum length of 6 bytes when the the encoded address will have a minimum length of 6 bytes when the
skipping to change at page 9, line 22 skipping to change at page 9, line 22
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 = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Rsvd2 | 8 + n | | Type = 4 | Rsvd2 | 8 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP TOS, IPv6 TC, or Flow Label | Protocol | | IP TOS, IPv6 TC, or Flow Label | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port | Remote Port | | Local Port (lower-range) | Local Port (upper-range) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Port (lower-range) | Remote Port (upper-range) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... | | AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of the AFI address that follows the Length value n: length in bytes of the AFI address that follows the
8-byte Application Data fields including the AFI field itself. 8-byte Application Data fields including the AFI field itself.
IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS IP TOS, IPv6 TC, or Flow Label: this field stores the 8-bit IPv4 TOS
field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow field used in an IPv4 header, the 8-bit IPv6 Traffic Class or Flow
Label used in an IPv6 header. Label used in an IPv6 header.
Local Port/Remote Port: these fields are from the TCP, UDP, or SCTP Local Port/Remote Port Ranges: these fields are from the TCP, UDP,
transport header. or SCTP transport header. A range can be specified by using a
lower value and an upper value. When a single port is encoded,
the lower and upper value fields are the same.
AFI = x: x can be any AFI value from [AFI]. AFI = x: x can be any AFI value from [AFI].
The Application Data Canonical Address Type is used for an EID The Application Data Canonical Address Type is used for an EID
encoding when an ITR wants a locator-set for a specific application. encoding when an ITR wants a locator-set for a specific application.
When used for an RLOC encoding, the ETR is supplying a locator-set When used for an RLOC encoding, the ETR is supplying a locator-set
for each specific application is has been configured to advertise. for each specific application is has been configured to advertise.
4.4. Assigning Geo Coordinates to Locator Addresses 4.4. Assigning Geo Coordinates to Locator Addresses
skipping to change at page 16, line 13 skipping to change at page 16, line 13
AFI = x: x can be any AFI value from [AFI]. AFI = x: x can be any AFI value from [AFI].
4.8. Multicast Group Membership Information 4.8. 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 an EID based group address can return a replication so a lookup on an EID based group address can return a replication
list of group addresses or a unicast addresses for single replication list of group addresses or a unicast addresses for single replication
or multiple head-end replications. The intent of this type of or multiple head-end replications. The intent of this type of
unicast replication is to deliver packets to multiple ETRs at 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 regsiter 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
acccording to [LISP-RE]), the Replication List Entry LCAF type is according to [LISP-RE]), the Replication List Entry LCAF type is used
used for locator encoding. for locator encoding.
This LCAF encoding can be used to send broadcast packets to all This LCAF encoding can be used to send broadcast packets to all
members of a subnet when each EIDs are away from their home subnet members of a subnet when each EIDs are away from their home subnet
location. location.
Multicast Info Canonical Address Format: Multicast Info 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Rsvd2 |R|L|J| 4 + n | | Type = 9 | Rsvd2 |R|L|J| 8 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source MaskLen| Group MaskLen | | Reserved | Source MaskLen| Group MaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Source/Subnet Address ... | | AFI = x | Source/Subnet Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Group Address ... | | AFI = x | Group Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow. Length value n: length in bytes of fields that follow.
skipping to change at page 17, line 11 skipping to change at page 17, line 15
L-bit: this is the Leave-Request bit and is used when this LCAF type L-bit: this is the Leave-Request bit and is used when this LCAF type
is present in the destination EID-prefix field of a Map-Request. is present in the destination EID-prefix field of a Map-Request.
See [LISP-MRSIG] for details. See [LISP-MRSIG] for details.
J-bit: this is the Join-Request bit and is used when this LCAF type J-bit: this is the Join-Request bit and is used when this LCAF type
is present in the destination EID-prefix field of a Map-Request. is present in the destination EID-prefix field of a Map-Request.
See [LISP-MRSIG] for details. The J-bit MUST not be set when the See [LISP-MRSIG] for details. The J-bit MUST not be set when the
L-bit is also set in the same LCAF block. A receiver should not L-bit is also set in the same LCAF block. A receiver should not
take any specific Join or Leave action when both bits are set. take any specific Join or Leave action when both bits are set.
Instance ID: the low-order 24-bits that can go into a LISP data
header when the I-bit is set. See [RFC6830] for details. The use
of the Instance-ID in this LCAF type is to associate a multicast
forwarding entry for a given VPN. The instance-ID describes the
VPN and is registered to the mapping database system as a 3-tuple
of (Instance-ID, S-prefix, G-prefix).
Source MaskLen: the mask length of the source prefix that follows. Source MaskLen: the mask length of the source prefix that follows.
Group MaskLen: the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix that follows.
AFI = x: x can be any AFI value from [AFI]. When a specific AFI has AFI = x: x can be any AFI value from [AFI]. When a specific AFI has
its own encoding of a multicast address, this field must be either its own encoding of a multicast address, this field must be either
a group address or a broadcast address. a group address or a broadcast address.
4.9. Traffic Engineering using Re-encapsulating Tunnels 4.9. Traffic Engineering using Re-encapsulating Tunnels
skipping to change at page 21, line 37 skipping to change at page 21, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value | | Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR/ETR #n ... | | AFI = x | RTR/ETR #n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow. Length value n: length in bytes of fields that follow.
Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Rsvd{1,2,3,4}: must be set to zero and ignore on receipt.
Level Value: this value is associated with the level of hierarchy Level Value: this value is associated with the level within the
the RTR resides in an overlay distribution tree. The level overlay distribution tree hierarchy where the RTR resides. The
numbers are ordered from lowest value being close to the ITR level numbers are ordered from lowest value being close to the ITR
(meaning that ITRs replicate to level-0 RTRs) and higher levels (meaning that ITRs replicate to level-0 RTRs) and higher levels
are further downstream on the distribution tree closer to ETRs of are further downstream on the distribution tree closer to ETRs of
multicast receiver sites. multicast receiver sites.
AFI = x: x can be any AFI value from [AFI]. A specific AFI has its AFI = x: x can be any AFI value from [AFI]. A specific AFI has its
own encoding of either a unicast or multicast locator address. own encoding of either a unicast or multicast locator address.
All RTR/ETR entries for the same level should be combined together All RTR/ETR entries for the same level should be combined together
by a Map-Server to avoid searching through the entire multi-level by a Map-Server to avoid searching through the entire multi-level
list of locator entries in a Map-Reply message. list of locator entries in a Map-Reply message.
4.13. Applications for AFI List Type 4.13. Data Model Encoding
4.13.1. Binding IPv4 and IPv6 Addresses This type allows a JSON data model to be encoded either as an EID or
RLOC.
JSON Data Model Type Address Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 | Rsvd2 |B| n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JSON binary or text encoding ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Optional Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow.
Rsvd{1,2}: must be set to zero and ignore on receipt.
B bit: indicates that the JSON field is binary encoded according to
[JSON-BINARY] when the bit is set to 1. Otherwise the encoding is
based on text encoding according to [RFC4627].
JSON field: a variable length field that contains either binary or
text encodings.
AFI = x: x can be any AFI value from [AFI]. A specific AFI has its
own encoding of either a unicast or multicast locator address.
All RTR/ETR entries for the same level should be combined together
by a Map-Server to avoid searching through the entire multi-level
list of locator entries in a Map-Reply message.
4.14. Encoding Key/Value Address Pairs
The Key/Value pair is for example useful for attaching attributes to
other elements of LISP packets, such as EIDs or RLOCs. When
attaching attributes to EIDs or RLOCs, it's necessary to distinguish
between the element that should be used as EID or RLOC, and hence as
key for lookups, and additional attributes. This is especially the
case when the difference cannot be determined from the types of the
elements, such as when two IP addresses are being used.
Key/Value Pair Address Format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 15 | Rsvd2 | n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address as Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address as Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow.
Rsvd{1,2}: must be set to zero and ignore on receipt.
AFI = x: x can be any AFI value from [AFI]. A specific AFI has its
own encoding of either a unicast or multicast locator address.
All RTR/ETR entries for the same level should be combined together
by a Map-Server to avoid searching through the entire multi-level
list of locator entries in a Map-Reply message.
Address as Key: this AFI encoded address will be attached with the
attributes encoded in "Address as Value" which follows this field.
Address as Value: this AFI encoded address will be the attribute
address that goes along with "Address as Key" which precedes this
field.
4.15. Applications for AFI List Type
4.15.1. Binding IPv4 and IPv6 Addresses
When header translation between IPv4 and IPv6 is desirable a LISP When header translation between IPv4 and IPv6 is desirable a LISP
Canonical Address can use the AFI List Type to carry multiple AFIs in Canonical Address can use the AFI List Type to carry multiple AFIs in
one LCA AFI. one LCAF AFI.
Bounded Address LISP Canonical Address Format: Address Binding 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 | | Type = 1 | Rsvd2 | 2 + 4 + 2 + 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 1 | IPv4 Address ... | | AFI = 1 | IPv4 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 5 skipping to change at page 25, line 5
Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI Length: length in bytes is fixed at 24 when IPv4 and IPv6 AFI
encoded addresses are used. encoded addresses are used.
This type of address format can be included in a Map-Request when the This type of address format can be included in a Map-Request when the
address is being used as an EID, but the Mapping Database System address is being used as an EID, but the Mapping Database System
lookup destination can use only the IPv4 address. This is so a lookup destination can use only the IPv4 address. This is so a
Mapping Database Service Transport System, such as LISP-ALT Mapping Database Service Transport System, such as LISP-ALT
[RFC6836], can use the Map-Request destination address to route the [RFC6836], can use the Map-Request destination address to route the
control message to the desired LISP site. control message to the desired LISP site.
4.13.2. Layer-2 VPNs 4.15.2. Layer-2 VPNs
When MAC addresses are stored in the LISP Mapping Database System, When MAC addresses are stored in the LISP Mapping Database System,
the AFI List Type can be used to carry AFI 6. the AFI List Type can be used to carry AFI 6.
MAC Address LISP Canonical Address Format: MAC Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
skipping to change at page 23, line 33 skipping to change at page 25, line 33
Length: length in bytes is fixed at 8 when MAC address AFI encoded Length: length in bytes is fixed at 8 when MAC address AFI encoded
addresses are used. addresses are used.
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. even another MAC address being used as an RLOC.
4.13.3. ASCII Names in the Mapping Database 4.15.3. ASCII Names in the Mapping Database
If DNS names or URIs are stored in the LISP Mapping Database System, If DNS names or URIs are stored in the LISP Mapping Database System,
the AFI List Type can be used to carry an ASCII string where it is the AFI List Type can be used to carry an ASCII string where it is
delimited by length 'n' of the LCAF Length encoding. delimited by length 'n' of the LCAF Length encoding.
ASCII LISP Canonical Address Format: ASCII 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Rsvd2 | 2 + n | | Type = 1 | Rsvd2 | 2 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 17 | DNS Name or URI ... | | AFI = 17 | DNS Name or URI ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes AFI=17 field and the null-terminated Length value n: length in bytes AFI=17 field and the null-terminated
ASCII string (the last byte of 0 is included). ASCII string (the last byte of 0 is included).
4.13.4. Using Recursive LISP Canonical Address Encodings 4.15.4. Using Recursive LISP Canonical Address Encodings
When any combination of above is desirable, the AFI List Type value When any combination of above is desirable, the AFI List Type value
can be used to carry within the LCA AFI another LCA AFI. can be used to carry within the LCAF AFI another LCAF AFI.
Recursive LISP Canonical Address Format: Recursive 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Rsvd2 | 4 + 8 + 2 + 4 | | Type = 1 | Rsvd2 | 4 + 8 + 2 + 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 5 skipping to change at page 27, line 5
This format could be used by a Mapping Database Transport System, This format could be used by a Mapping Database Transport System,
such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as
an EID and placed in the Map-Request destination address by the an EID and placed in the Map-Request destination address by the
sending LISP system. The ALT system can deliver the Map-Request to sending LISP system. The ALT system can deliver the Map-Request to
the LISP destination site independent of the Application Data Type the LISP destination site independent of the Application Data Type
AFI payload values. When this AFI is processed by the destination AFI payload values. When this AFI is processed by the destination
LISP site, it can return different locator-sets based on the type of LISP site, it can return different locator-sets based on the type of
application or level of service that is being requested. application or level of service that is being requested.
4.13.5. Compatibility Mode Use Case 4.15.5. Compatibility Mode Use Case
A LISP system should use the AFI List Type format when sending to A LISP system should use the AFI List Type format when sending to
LISP systems that do not support a particular LCAF Type used to LISP systems that do not support a particular LCAF Type used to
encode locators. This allows the receiving system to be able to encode locators. This allows the receiving system to be able to
parse a locator address for encapsulation purposes. The list of AFIs parse a locator address for encapsulation purposes. The list of AFIs
in an AFI List LCAF Type has no semantic ordering and a receiver in an AFI List LCAF Type has no semantic ordering and a receiver
should parse each AFI element no matter what the ordering. should parse each AFI element no matter what the ordering.
Compatibility Mode Address Format: Compatibility Mode Address Format:
skipping to change at page 28, line 16 skipping to change at page 30, line 16
7.1. Normative References 7.1. Normative References
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
7.2. Informative References 7.2. Informative References
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/numbers.html, Febuary 2007. NUMBERS http://www.iana.org/numbers.html, Febuary 2007.
[JSON-BINARY]
"Universal Binary JSON Specification",
URL http://ubjson.org.
[LISP-DDT] [LISP-DDT]
Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated Fuller, V., Lewis, D., and V. Ermagan, "LISP Delegated
Database Tree", draft-fuller-lisp-ddt-01.txt (work in Database Tree", draft-ietf-lisp-ddt-01.txt (work in
progress). progress).
[LISP-MRSIG] [LISP-MRSIG]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", Multicast Signaling",
draft-farinacci-lisp-mr-signaling-00.txt (work in draft-farinacci-lisp-mr-signaling-03.txt (work in
progress). progress).
[LISP-NATT] [LISP-NATT]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", F., and C. White, "NAT traversal for LISP",
draft-ermagan-lisp-nat-traversal-00.txt (work in draft-ermagan-lisp-nat-traversal-03.txt (work in
progress). progress).
[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-02.txt (work in Engineering", draft-coras-lisp-re-03.txt (work in
progress). progress).
[LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic [LISP-TE] Farinacci, D., Lahiri, P., and M. Kowal, "LISP Traffic
Engineering Use-Cases", draft-farinacci-lisp-te-01.txt Engineering Use-Cases", draft-farinacci-lisp-te-03.txt
(work in progress). (work in progress).
[WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic [WGS-84] Geodesy and Geophysics Department, DoD., "World Geodetic
System 1984", NIMA TR8350.2, January 2000, <http:// System 1984", NIMA TR8350.2, January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/ earth-info.nga.mil/GandG/publications/tr8350.2/
wgs84fin.pdf>. wgs84fin.pdf>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Vince Fuller, Gregg Schudel, Jesper The authors would like to thank Vince Fuller, Gregg Schudel, Jesper
skipping to change at page 30, line 26 skipping to change at page 32, line 26
(ELP) LCAF type. (ELP) LCAF type.
The authors would like to thank Fabio Maino and Vina Ermagan for The authors would like to thank Fabio Maino and Vina Ermagan for
discussions that lead to the definition of the Security Key LCAF discussions that lead to the definition of the Security Key LCAF
type. type.
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
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.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-lcaf-02.txt B.1. Changes to draft-ietf-lisp-lcaf-03.txt
o Submitted September 2013.
o Updated references and author's affilations.
o Added Instance-ID to the Multicast Info Type so there is relative
ease in parsing (S,G) entries within a VPN.
o Add port range encodings to the Application Data LCAF Type.
o Add a new JSON LCAF Type.
o Add Address Key/Value LCAF Type to allow attributes to be attached
to an address.
B.2. 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.2. Changes to draft-ietf-lisp-lcaf-01.txt B.3. 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.3. Changes to draft-ietf-lisp-lcaf-00.txt B.4. 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
cisco Systems lispers.net
Tasman Drive San Jose, CA
San Jose, CA 95134
USA USA
Email: farinacci@gmail.com Email: farinacci@gmail.com
Dave Meyer Dave Meyer
cisco Systems Brocade
170 Tasman Drive
San Jose, CA San Jose, CA
USA USA
Email: dmm@cisco.com Email: dmm@1-4-5.net
Job Snijders Job Snijders
InTouch N.V. Hibernia Networks
Middenweg 76 Tupolevlaan 103a
1097 BS Amsterdam Schiphol-Rijk, 1119 PA
The Netherlands NL
Email: job@instituut.net Email: job.snijders@hibernianetworks.com
 End of changes. 37 change blocks. 
61 lines changed or deleted 183 lines changed or added

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