draft-ietf-lisp-lcaf-01.txt   draft-ietf-lisp-lcaf-02.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental cisco Systems Intended status: Experimental cisco Systems
Expires: July 11, 2013 J. Snijders Expires: September 11, 2013 J. Snijders
InTouch N.V. InTouch N.V.
January 7, 2013 March 10, 2013
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-01 draft-ietf-lisp-lcaf-02
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 34
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 July 11, 2013. This Internet-Draft will expire on September 11, 2013.
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 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . 7
4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7 4.1. Segmentation using LISP . . . . . . . . . . . . . . . . . 7
4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8 4.2. Carrying AS Numbers in the Mapping Database . . . . . . . 8
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 . . . . . . . . . . . . . 11 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 . . . . . . . . . . . 14 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 . . . . 17 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. Applications for AFI List Type . . . . . . . . . . . . . . 21 4.12. Replication List Entries for Multicast Forwarding . . . . 21
4.12.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 21 4.13. Applications for AFI List Type . . . . . . . . . . . . . . 22
4.12.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 22 4.13.1. Binding IPv4 and IPv6 Addresses . . . . . . . . . . . 22
4.12.3. ASCII Names in the Mapping Database . . . . . . . . . 22 4.13.2. Layer-2 VPNs . . . . . . . . . . . . . . . . . . . . 23
4.12.4. Using Recursive LISP Canonical Address Encodings . . 23 4.13.3. ASCII Names in the Mapping Database . . . . . . . . . 23
4.12.5. Compatibility Mode Use Case . . . . . . . . . . . . . 24 4.13.4. Using Recursive LISP Canonical Address Encodings . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 4.13.5. Compatibility Mode Use Case . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . . 27 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 30
B.1. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 30 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 31
B.2. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 30 B.1. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 B.2. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . . 31
B.3. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
The LISP architecture and protocols [LISP] 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.
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:
skipping to change at page 6, line 10 skipping to change at page 6, line 10
Type 8: Nonce Locator Type Type 8: Nonce Locator Type
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
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 7, line 42 skipping to change at page 7, line 42
IID mask-len: if the AFI is set to 0, then this format is not IID mask-len: if the AFI is set to 0, then this format is not
encoding an extended EID-prefix but rather an instance-ID range encoding an extended EID-prefix but rather an instance-ID range
where the 'IID mask-len' indicates the number of high-order bits where the 'IID mask-len' indicates the number of high-order bits
used in the Instance ID field for the range. used in the Instance ID field for the range.
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
Instance ID field including the AFI field itself. Instance ID field including the AFI field itself.
Instance ID: the low-order 24-bits that can go into a LISP data Instance ID: the low-order 24-bits that can go into a LISP data
header when the I-bit is set. See [LISP] for details. header when the I-bit is set. See [RFC6830] for details.
AFI = x: x can be any AFI value from [AFI]. AFI = x: x can be any AFI value from [AFI].
This LISP Canonical Address Type can be used to encode either EID or This LISP Canonical Address Type can be used to encode either EID or
RLOC addresses. RLOC addresses.
4.2. Carrying AS Numbers in the Mapping Database 4.2. Carrying AS Numbers in the Mapping Database
When an AS number is stored in the LISP Mapping Database System for When an AS number is stored in the LISP Mapping Database System for
either policy or documentation reasons, it can be encoded in a LISP either policy or documentation reasons, it can be encoded in a LISP
skipping to change at page 16, line 10 skipping to change at page 16, line 10
locator-record to be used by an ITR or PITR when encapsulating to locator-record to be used by an ITR or PITR when encapsulating to
the locator address encoded in the AFI field of this LCAF type. the locator address encoded in the AFI field of this LCAF type.
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. This LCAF encoding can be used to or multiple head-end replications. The intent of this type of
send broadcast packets to all members of a subnet when each EIDs are unicast replication is to deliver packets to multiple ETRs at
away from their home subnet location. 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
Semantics". The encoding can be a typical AFI encoded locator
address. When an RTR list is being registered (with multiple levels
acccording to [LISP-RE]), the Replication List Entry LCAF type is
used for locator encoding.
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
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| 4 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 5 skipping to change at page 21, line 5
Source-ML: the mask length of the source prefix that follows. Source-ML: the mask length of the source prefix that follows.
Dest-ML: the mask length of the destination prefix that follows. Dest-ML: the mask length of the destination 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.
Refer to [LISP-TE] for usage details. Refer to [LISP-TE] for usage details.
4.12. Applications for AFI List Type 4.12. Replication List Entries for Multicast Forwarding
4.12.1. Binding IPv4 and IPv6 Addresses The Replication List Entry LCAF type is an encoding for a locator
being used for unicast replication according to the specification in
[LISP-RE]. This locator encoding is pointed to by a Multicast Info
LCAF Type and is registered by Re-encapsulating Tunnel Routers (RTRs)
that are participating in an overlay distribution tree. Each RTR
will register its locator address and its configured level in the
distribution tree.
Replication List Entry 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 = 13 | Rsvd2 | 4 + n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR/ETR #1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR/ETR #n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length value n: length in bytes of fields that follow.
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
the RTR resides in an overlay distribution tree. The level
numbers are ordered from lowest value being close to the ITR
(meaning that ITRs replicate to level-0 RTRs) and higher levels
are further downstream on the distribution tree closer to ETRs of
multicast receiver sites.
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.13. Applications for AFI List Type
4.13.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 LCA AFI.
Bounded Address LISP Canonical Address Format: Bounded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 41 skipping to change at page 22, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv6 Address | | ... IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [ALT], Mapping Database Service Transport System, such as LISP-ALT
can use the Map-Request destination address to route the control [RFC6836], can use the Map-Request destination address to route the
message to the desired LISP site. control message to the desired LISP site.
4.12.2. Layer-2 VPNs 4.13.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 22, line 33 skipping to change at page 23, 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.12.3. ASCII Names in the Mapping Database 4.13.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.12.4. Using Recursive LISP Canonical Address Encodings 4.13.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 LCA AFI another LCA 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 |
skipping to change at page 23, line 39 skipping to change at page 24, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 1 | IPv4 Address ... | | AFI = 1 | IPv4 Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IPv4 Address | | ... IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: length in bytes is fixed at 18 when an AFI=1 IPv4 address is Length: length in bytes is fixed at 18 when an AFI=1 IPv4 address is
included. included.
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 [ALT], where the AFI=1 IPv4 address is used as an such as LISP-ALT [RFC6836], where the AFI=1 IPv4 address is used as
EID and placed in the Map-Request destination address by the sending an EID and placed in the Map-Request destination address by the
LISP system. The ALT system can deliver the Map-Request to the LISP sending LISP system. The ALT system can deliver the Map-Request to
destination site independent of the Application Data Type AFI payload the LISP destination site independent of the Application Data Type
values. When this AFI is processed by the destination LISP site, it AFI payload values. When this AFI is processed by the destination
can return different locator-sets based on the type of application or LISP site, it can return different locator-sets based on the type of
level of service that is being requested. application or level of service that is being requested.
4.12.5. Compatibility Mode Use Case 4.13.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 26, line 15 skipping to change at page 27, line 15
6. IANA Considerations 6. IANA Considerations
The Address Family AFI definitions from [AFI] only allocate code- The Address Family AFI definitions from [AFI] only allocate code-
points for the AFI value itself. The length of the address or entity points for the AFI value itself. The length of the address or entity
that follows is not defined and is implied based on conventional that follows is not defined and is implied based on conventional
experience. Where the LISP protocol uses LISP Canonical Addresses experience. Where the LISP protocol uses LISP Canonical Addresses
specifically, the address length definitions will be in this specifically, the address length definitions will be in this
specification and take precedent over any other specification. specification and take precedent over any other specification.
An IANA Registry for LCAF Type values will be created. The values An IANA Registry for LCAF Type values will be created. The values
that are considered for use by the main LISP specification [LISP] that are considered for use by the main LISP specification [RFC6830]
will be in the IANA Registry. Other Type values used for will be in the IANA Registry. Other Type values used for
experimentation will be defined and described in this document. experimentation will be defined and described in this document.
7. References 7. References
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.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
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.
[ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)",
draft-ietf-lisp-alt-06.txt (work in progress), March 2011.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-12.txt (work in progress), April 2011.
[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-fuller-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-00.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-00.txt (work in
progress). progress).
[LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-02.txt (work in
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-01.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
skipping to change at page 29, line 22 skipping to change at page 30, line 22
lead to the definition of the Multicast Info LCAF type. lead to the definition of the Multicast Info LCAF type.
The authors would like to thank Parantap Lahiri and Michael Kowal for The authors would like to thank Parantap Lahiri and Michael Kowal for
discussions that lead to the definition of the Explicit Locator Path discussions that lead to the definition of the Explicit Locator Path
(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
Coras for discussions that lead to the definition of the Replication
List Entry LCAF type.
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-01.txt B.1. Changes to draft-ietf-lisp-lcaf-02.txt
o Submitted March 2013.
o Added new LCAF Type "Replication List Entry" to support LISP
replication engineering use-cases.
o Changed references to new LISP RFCs.
B.2. 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.2. Changes to draft-ietf-lisp-00.txt B.3. 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 cisco Systems
Tasman Drive Tasman Drive
 End of changes. 27 change blocks. 
55 lines changed or deleted 131 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/