draft-ietf-lisp-lcaf-17.txt   draft-ietf-lisp-lcaf-18.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: April 15, 2017 Brocade Expires: April 17, 2017 Brocade
J. Snijders J. Snijders
NTT Communications NTT Communications
October 12, 2016 October 14, 2016
LISP Canonical Address Format (LCAF) LISP Canonical Address Format (LCAF)
draft-ietf-lisp-lcaf-17 draft-ietf-lisp-lcaf-18
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.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
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 April 15, 2017. This Internet-Draft will expire on April 17, 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 40 skipping to change at page 2, line 40
4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24 4.10.3. ASCII Names in the Mapping Database . . . . . . . . 24
4.10.4. Using Recursive LISP Canonical Address Encodings . . 25 4.10.4. Using Recursive LISP Canonical Address Encodings . . 25
4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26 4.10.5. Compatibility Mode Use Case . . . . . . . . . . . . 26
5. Experimental LISP Canonical Address Applications . . . . . . 27 5. Experimental LISP Canonical Address Applications . . . . . . 27
5.1. Convey Application Specific Data . . . . . . . . . . . . 27 5.1. Convey Application Specific Data . . . . . . . . . . . . 27
5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 29 5.2. Generic Database Mapping Lookups . . . . . . . . . . . . 29
5.3. PETR Admission Control Functionality . . . . . . . . . . 30 5.3. PETR Admission Control Functionality . . . . . . . . . . 30
5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31 5.4. Data Model Encoding . . . . . . . . . . . . . . . . . . . 31
5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32 5.5. Encoding Key/Value Address Pairs . . . . . . . . . . . . 32
5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33 5.6. Multiple Data-Planes . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Normative References . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . 36
8.2. Informative References . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40
B.1. Changes to draft-ietf-lisp-lcaf-17.txt . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-lcaf-18.txt . . . . . . . . . 40
B.2. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-lcaf-17.txt . . . . . . . . . 40
B.3. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-lcaf-16.txt . . . . . . . . . 40
B.4. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-lcaf-15.txt . . . . . . . . . 40
B.5. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-lcaf-14.txt . . . . . . . . . 40
B.6. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 40 B.6. Changes to draft-ietf-lisp-lcaf-13.txt . . . . . . . . . 41
B.7. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-lcaf-12.txt . . . . . . . . . 41
B.8. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-lcaf-11.txt . . . . . . . . . 41
B.9. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-lcaf-10.txt . . . . . . . . . 41
B.10. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41 B.10. Changes to draft-ietf-lisp-lcaf-09.txt . . . . . . . . . 41
B.11. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-lcaf-08.txt . . . . . . . . . 41
B.12. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-lcaf-07.txt . . . . . . . . . 42
B.13. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-lcaf-06.txt . . . . . . . . . 42
B.14. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42 B.14. Changes to draft-ietf-lisp-lcaf-05.txt . . . . . . . . . 42
B.15. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42 B.15. Changes to draft-ietf-lisp-lcaf-04.txt . . . . . . . . . 42
B.16. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 42 B.16. Changes to draft-ietf-lisp-lcaf-03.txt . . . . . . . . . 42
B.17. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 43 B.17. Changes to draft-ietf-lisp-lcaf-02.txt . . . . . . . . . 43
B.18. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 43 B.18. Changes to draft-ietf-lisp-lcaf-01.txt . . . . . . . . . 43
B.19. Changes to draft-ietf-lisp-lcaf-00.txt . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
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.
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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:
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 = 0 | <nothing follows AFI=0> | | AFI = 0 | <no address follows>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value
used in the source and destination address fields of the first used in the source and destination address fields of the first
(most inner) LISP header of a packet. The host obtains a (most inner) LISP header of a packet. The host obtains a
destination EID the same way it obtains a destination address destination EID the same way it obtains a destination address
today, for example through a DNS lookup or SIP exchange. The today, for example through a DNS lookup or SIP exchange. The
source EID is obtained via existing mechanisms used to set a source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts. located. An EID can be used by a host to refer to other hosts.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
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 | Rsvd2 | Length | | Type | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | | . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd1: this 8-bit field is reserved for future use and MUST be Rsvd1/Rsvd2: these 8-bit fields are reserved for future use and MUST
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 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 39 skipping to change at page 6, line 39
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 14: JSON Data Model Type
Type 15: Key/Value Address Pair Type Type 15: Key/Value Address Pair Type
Type 16: Encapsulation Format Type Type 16: Encapsulation Format Type
Rsvd2: this LCAF Type-dependent 8-bit field is reserved for future
use and MUST be transmitted as 0 and ignored on receipt. See
specific LCAF Type for specific bits not reserved.
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, Reserved, field is 0. The 8 bytes include the AFI, Flags, Type, Rsvd1,
and Length fields. When the AFI is not next to an encoded address Rsvd2, and Length fields. When the AFI is not next to an encoded
in a control message, then the encoded address will have a minimum address in a control message, then the encoded address will have a
length of 6 bytes when the Length field is 0. The 6 bytes include minimum length of 6 bytes when the Length field is 0. The 6 bytes
the Flags, Type, Reserved, 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 are sorted when encoded in control
messages so the locator-set has consistent order across all xTRs for messages so the locator-set has consistent order across all xTRs for
a given EID. The sort order is based on sort-key {afi, RLOC- a given EID. The sort order is based on sort-key {afi, RLOC-
address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF- address}. When an RLOC is LCAF encoded, the sort-key is {afi, LCAF-
Type}. Therefore, when a locator-set has a mix of AFI records and Type}. Therefore, when a locator-set has a mix of AFI records and
LCAF records, they are ordered from smallest to largest AFI value. LCAF records, they are ordered from smallest to largest AFI value.
4. LISP Canonical Address Applications 4. LISP Canonical Address Applications
skipping to change at page 8, line 47 skipping to change at page 8, line 43
limiting the maximum number of instances per xTR to 2^24. If an limiting the maximum number of instances per xTR to 2^24. If an
xTR is configured with multiple instance-IDs where the value in xTR is configured with multiple instance-IDs where the value in
the high-order 8 bits are the same, then the low-order 24 bits the high-order 8 bits are the same, then the low-order 24 bits
MUST be unique. MUST be unique.
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.
Usage: When used as a lookup key, the EID is regarded as a extended- Usage: When used as a lookup key, the EID is regarded as an extended-
EID in the mapping system. This encoding is used in EID records in EID in the mapping system. This encoding is used in EID records in
Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages. Map-Requests, Map-Replies, Map-Registers, and Map-Notify messages.
When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system When LISP-DDT [I-D.ietf-lisp-ddt] is used as the mapping system
mechanism, extended EIDs are used in Map-Referral messages. mechanism, extended EIDs are used in Map-Referral messages.
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
Canonical Address. Canonical Address.
skipping to change at page 9, line 29 skipping to change at page 9, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number | | AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... | | AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
AS Number: the 32-bit AS number of the autonomous system that has AS Number: the 32-bit AS number of the autonomous system that has
been assigned either the EID or RLOC that follows. been assigned to either the EID or RLOC that follows.
AFI = x: x can be any AFI value from [AFI]. AFI = x: x can be any AFI value from [AFI].
The AS Number Canonical Address Type can be used to encode either EID The AS Number Canonical Address Type can be used to encode either EID
or RLOC addresses. The former is used to describe the LISP-ALT AS or RLOC addresses. The former is used to describe the LISP-ALT AS
number the EID-prefix for the site is being carried for. The latter number the EID-prefix for the site is being carried for. The latter
is used to describe the AS that is carrying RLOC based prefixes in is used to describe the AS that is carrying RLOC based prefixes in
the underlying routing system. the underlying routing system.
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-
skipping to change at page 13, line 15 skipping to change at page 13, line 15
Private ETR RLOC Address: this is an address known to be a private Private ETR RLOC Address: this is an address known to be a private
address inserted in this LCAF by a LISP router that resides on the address inserted in this LCAF by a LISP router that resides on the
private side of a NAT device. private side of a NAT device.
RTR RLOC Address: this is an encapsulation address used by an ITR or RTR RLOC Address: this is an encapsulation address used by an ITR or
PITR which resides behind a NAT device. This address is known to PITR which resides behind a NAT device. This address is known to
have state in a NAT device so packets can flow from it to the LISP have state in a NAT device so packets can flow from it to the LISP
ETR behind the NAT. There can be one or more NAT Reencapsulating ETR behind the NAT. There can be one or more NAT Reencapsulating
Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses Tunnel Router (RTR) [I-D.ermagan-lisp-nat-traversal] addresses
supplied in these set of fields. The number of RTRs encoded is supplied in these set of fields. The number of RTRs encoded is
determined by the LCAF length 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.
4.5. Multicast Group Membership Information 4.5. Multicast Group Membership Information
skipping to change at page 14, line 19 skipping to change at page 14, line 19
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
according to [I-D.coras-lisp-re]), the Replication List Entry LCAF according to [I-D.coras-lisp-re]), the Replication List Entry LCAF
type is used for locator encoding. type is used 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 an EID is away from it's home subnet members of a subnet when an EID is away from its 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 | Length | | Type = 9 | Rsvd2 | Length |
skipping to change at page 15, line 15 skipping to change at page 15, line 15
Source MaskLen: the mask length of the source prefix that follows. Source MaskLen: the mask length of the source prefix that follows.
The length is the number of high-order mask bits set. The length is the number of high-order mask bits set.
Group MaskLen: the mask length of the group prefix that follows. Group MaskLen: the mask length of the group prefix that follows.
The length is the number of high-order mask bits set. The length is the number of high-order mask bits set.
AFI = x: x can be any AFI value from [AFI]. When a specific address AFI = x: x can be any AFI value from [AFI]. When a specific address
family has a multicast address semantic, this field must be either family has a multicast address semantic, this field must be either
a group address or a broadcast address. a group address or a broadcast address.
Source/Subnet Address is the source address or prefix for encoding a Source/Subnet Address: is the source address or prefix for encoding
(S,G) multicast entry. a (S,G) multicast entry.
Group Address is the group address or group prefix for encoding Group Address: is the group address or group prefix for encoding
(S,G) or (*,G) multicast entries. (S,G) or (*,G) multicast entries.
Usage: This encoding can be used in EID records in Map-Requests, Map- Usage: This encoding can be used in EID records in Map-Requests, Map-
Replies, Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. When LISP-DDT
[I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended
EIDs are used in Map-Referral messages. EIDs are used in Map-Referral messages.
4.6. Traffic Engineering using Re-encapsulating Tunnels 4.6. Traffic Engineering using Re-encapsulating Tunnels
For a given EID lookup into the mapping database, this LCAF can be For a given EID lookup into the mapping database, this LCAF can be
skipping to change at page 16, line 49 skipping to change at page 16, line 49
RLOC-Probe bit (P): this is the RLOC-probe bit which means the RLOC-Probe bit (P): this is the RLOC-probe bit which means the
Reencap Hop allows RLOC-probe messages to be sent to it. When the Reencap Hop allows RLOC-probe messages to be sent to it. When the
R-bit is set to 0, RLOC-probes must not be sent. When a Reencap R-bit is set to 0, RLOC-probes must not be sent. When a Reencap
Hop is an anycast address then multiple physical Reencap Hops are Hop is an anycast address then multiple physical Reencap Hops are
using the same RLOC address. In this case, RLOC-probes are not using the same RLOC address. In this case, RLOC-probes are not
needed because when the closest RLOC address is not reachable needed because when the closest RLOC address is not reachable
another RLOC address can be reachable. another RLOC address can be reachable.
Strict bit (S): this is the strict bit which means the associated Strict bit (S): this is the strict bit which means the associated
Rencap Hop is required to be used. If this bit is 0, the Reencap Hop is required to be used. If this bit is 0, the
reencapsulator can skip this Reencap Hop and go to the next one in reencapsulator can skip this Reencap Hop and go to the next one in
the list. the list.
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.
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. This encoding Map-Replies, Map-Registers, and Map-Notify messages. This encoding
does not need to be understood by the mapping system for mapping does not need to be understood by the mapping system for mapping
skipping to change at page 18, line 27 skipping to change at page 18, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Key Material | | ... Key Material |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Locator Address ... | | AFI = x | Locator Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Key Count: the Key Count field declares the number of Key sections Key Count: the Key Count field declares the number of Key sections
included in this LCAF. A key section is made up the "Key Length" included in this LCAF. A key section is made up of "Key Length"
and "Key Material" fields. and "Key Material" fields.
Rsvd3: this field is reserved for future use and MUST be transmitted Rsvd3: this field is reserved for future use and MUST be transmitted
as 0 and ignored on receipt. as 0 and ignored on receipt.
Key Algorithm: the Algorithm field identifies the key's Key Algorithm: the Algorithm field identifies the key's
cryptographic algorithm and specifies the format of the Public Key cryptographic algorithm and specifies the format of the Public Key
field. Refer to the [I-D.ietf-lisp-ddt] and field. Refer to the [I-D.ietf-lisp-ddt] and
[I-D.ietf-lisp-crypto] use cases for definitions of this field. [I-D.ietf-lisp-crypto] use cases for definitions of this field.
skipping to change at page 18, line 51 skipping to change at page 18, line 51
R bit: this is the revoke bit and, if set, it specifies that this R bit: this is the revoke bit and, if set, it specifies that this
Key is being Revoked. Key is being Revoked.
Key Length: this field determines the length in bytes of the Key Key Length: this field determines the length in bytes of the Key
Material field. Material field.
Key Material: the Key Material field stores the key material. The Key Material: the Key Material field stores the key material. The
format of the key material stored depends on the Key Algorithm format of the key material stored depends on the Key Algorithm
field. field.
AFI = x: x can be any AFI value from [AFI].This is the locator AFI = x: x can be any AFI value from [AFI]. This is the locator
address that owns the encoded security key. address that owns the encoded security key.
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.
4.8. Source/Destination 2-Tuple Lookups 4.8. Source/Destination 2-Tuple Lookups
When both a source and destination address of a flow need When both a source and destination address of a flow need
skipping to change at page 20, line 18 skipping to change at page 20, line 18
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 = 12 | Rsvd2 | Length | | Type = 12 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source-ML | Dest-ML | | Reserved | Source-ML | Dest-ML |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Source-Prefix ... | | AFI = x | Source-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Destination-Prefix ... | | AFI = y | Destination-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Reserved: must be set to zero and ignore on receipt. Reserved: must be set to zero and ignore on receipt.
Source-ML: the mask length of the source prefix that follows. The Source-ML: the mask length of the source prefix that follows. The
length is the number of high-order mask bits set. length is the number of high-order mask bits set.
Dest-ML: the mask length of the destination prefix that follows. Dest-ML: the mask length of the destination prefix that follows.
The length is the number of high-order mask bits set. The length is the number of high-order mask bits set.
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].
its own encoding of a multicast address, this field must be either
AFI = y: y can be any AFI value from [AFI]. When a specific address
family has a multicast address semantic, this field must be either
a group address or a broadcast address. a group address or a broadcast address.
Usage: This encoding can be used in EID records in Map-Requests, Map- Usage: This encoding can be used in EID records in Map-Requests, Map-
Replies, Map-Registers, and Map-Notify messages. When LISP-DDT Replies, Map-Registers, and Map-Notify messages. When LISP-DDT
[I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended [I-D.ietf-lisp-ddt] is used as the mapping system mechanism, extended
EIDs are used in Map-Referral messages. Refer to EIDs are used in Map-Referral messages. Refer to
[I-D.farinacci-lisp-te] for usage details of this LCAF type. [I-D.farinacci-lisp-te] for usage details of this LCAF type.
4.9. Replication List Entries for Multicast Forwarding 4.9. Replication List Entries for Multicast Forwarding
skipping to change at page 21, line 36 skipping to change at page 21, line 36
| AFI = x | RTR/ETR #1 ... | | AFI = x | RTR/ETR #1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd3 | Rsvd4 | Level Value | | Rsvd3 | Rsvd4 | Level Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | RTR/ETR #n ... | | AFI = x | RTR/ETR #n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Rsvd{1,2,3,4}: must be set to zero and ignore on receipt. Rsvd3/Rsvd4: must be set to zero and ignore on receipt.
Level Value: this value is associated with the level within the Level Value: this value is associated with the level within the
overlay distribution tree hierarchy where the RTR resides. The overlay distribution tree hierarchy where the RTR resides. The
level 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.
skipping to change at page 23, line 33 skipping to change at page 23, 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. doing EID mobility. Refer to the Security Considerations section for
privacy protection.
4.10.3. ASCII Names in the Mapping Database 4.10.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.
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 | Length | | Type = 1 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 47 skipping to change at page 26, line 47
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.
Length2: length in bytes starting and including the byte after this Length2: length in bytes starting and including the byte after this
Length2 field. Length2 field.
If a system does not recognized the Geo Coordinate LCAF Type that is If a system does not recognized the Geo Coordinate LCAF Type that is
accompanying a locator address, an encoder can include the Geo accompanying a locator address, an encoder can include the Geo
Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI Coordinate LCAF Type embedded in a AFI List LCAF Type where the AFI
in the Geo Coordinate LCAF is set to 0 and the AFI-encoded next in in the Geo Coordinate LCAF is set to 0 and the AFI encoded next in
the list is encoded with a valid AFI value to identify the locator the list is encoded with a valid AFI value to identify the locator
address. address.
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.
skipping to change at page 29, line 28 skipping to change at page 29, line 28
| Type = 6 | Rsvd2 | Length | | Type = 6 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Field Num | Key Wildcard Fields | Key . . . | | Key Field Num | Key Wildcard Fields | Key . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Key | | . . . Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Key Field Num: the value of this field is the the number of "Key" Key Field Num: the value of this field is the number of "Key" sub-
sub-fields minus 1, the "Key" field can be broken up into. So if fields minus 1, the "Key" field can be broken up into. So if this
this field has a value of 0, there is 1 sub-field in the "Key". field has a value of 0, there is 1 sub-field in the "Key". The
The width of the sub-fields are fixed length. So for a key size width of the sub-fields are fixed length. So for a key size of 8
of 8 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes, with a Key Field Num of 3, allows 4 sub-fields of 2 bytes
bytes each in length. Allowing for a reasonable number of 16 sub- each in length. Allowing for a reasonable number of 16 sub-field
field separators, valid values range from 0 to 15. separators, valid values range from 0 to 15.
Key Wildcard Fields: describes which fields in the key are not used Key Wildcard Fields: describes which fields in the key are not used
as part of the key lookup. This wildcard encoding is a bitfield. as part of the key lookup. This wildcard encoding is a bitfield.
Each bit is a don't-care bit for a corresponding field in the key. Each bit is a don't-care bit for a corresponding field in the key.
Bit 0 (the low-order bit) in this bitfield corresponds the first Bit 0 (the low-order bit) in this bitfield corresponds the first
field, the low-order field in the key, bit 1 the second field, and field, the low-order field in the key, bit 1 the second field, and
so on. When a bit is set in the bitfield it is a don't-care bit so on. When a bit is set in the bitfield it is a don't-care bit
and should not be considered as part of the database lookup. When and should not be considered as part of the database lookup. When
the entire 16-bits is set to 0, then all bits of the key are used the entire 16-bits is set to 0, then all bits of the key are used
for the database lookup. for the database lookup.
skipping to change at page 31, line 27 skipping to change at page 31, line 27
| Type = 14 | Rsvd2 |B| Length | | Type = 14 | Rsvd2 |B| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JSON length | JSON binary/text encoding ... | | JSON length | JSON binary/text encoding ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Optional Address ... | | AFI = x | Optional Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Rsvd{1,2}: must be set to zero and ignore on receipt.
B bit: indicates that the JSON field is binary encoded according to 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 [JSON-BINARY] when the bit is set to 1. Otherwise the encoding is
based on text encoding according to [RFC7159]. based on text encoding according to [RFC7159].
JSON length: length in octets of the following 'JSON binary/text JSON length: length in octets of the following 'JSON binary/text
encoding' field. encoding' field.
JSON binary/text encoding field: a variable length field that JSON binary/text encoding field: a variable length field that
contains either binary or text encodings. contains either binary or text encodings.
skipping to change at page 32, line 11 skipping to change at page 32, line 11
Usage: This is an experimental type where the usage has not been Usage: This is an experimental type where the usage has not been
defined yet. defined yet.
5.5. Encoding Key/Value Address Pairs 5.5. Encoding Key/Value Address Pairs
The Key/Value pair is, for example, useful for attaching attributes The Key/Value pair is, for example, useful for attaching attributes
to other elements of LISP packets, such as EIDs or RLOCs. When to other elements of LISP packets, such as EIDs or RLOCs. When
attaching attributes to EIDs or RLOCs, it's necessary to distinguish 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 between the element that should be used as EID or RLOC, and hence as
key for lookups, and additional attributes. This is especially the the key for lookups, and additional attributes. This is especially
case when the difference cannot be determined from the types of the the case when the difference cannot be determined from the types of
elements, such as when two IP addresses are being used. the elements, such as when two IP addresses are being used.
Key/Value Pair Address Format: Key/Value Pair 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 = 15 | Rsvd2 | Length | | Type = 15 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address as Key ... | | AFI = x | Address as Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = y | Address as Value ... | | AFI = y | Address as Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Rsvd{1,2}: must be set to zero and ignore on receipt.
AFI = x: x is the "Address as Key" AFI that can have any value from AFI = x: x is the "Address as Key" AFI that can have any value from
[AFI]. A specific AFI has its own encoding of either a unicast or [AFI]. A specific AFI has its own encoding of either a unicast or
multicast locator address. All RTR/ETR entries for the same level multicast locator address. All RTR/ETR entries for the same level
should be combined together by a Map-Server to avoid searching should be combined together by a Map-Server to avoid searching
through the entire multi-level list of locator entries in a Map- through the entire multi-level list of locator entries in a Map-
Reply message. Reply message.
Address as Key: this AFI-encoded address will be attached with the Address as Key: this AFI-encoded address will be attached with the
attributes encoded in "Address as Value" which follows this field. attributes encoded in "Address as Value" which follows this field.
skipping to change at page 34, line 19 skipping to change at page 34, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags | | AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Rsvd2 | Length | | Type = 16 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L| | Reserved-for-Future-Encapsulations |U|G|N|v|V|l|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... | | AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd1/Rsvd2: must be set to zero and ignored on receipt.
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.
Reserved-for-Future-Encapsulations: must be set to zero and ignored Reserved-for-Future-Encapsulations: must be set to zero and ignored
on receipt. This field will get bits allocated to future on receipt. This field will get bits allocated to future
encapsulations, as they are created. encapsulations, as they are created.
L: The RLOCs listed in the AFI-encoded addresses in the next longword L: The RLOCs listed in the AFI-encoded addresses in the next longword
can accept layer 3 LISP encapsulation using destination UDP port can accept layer 3 LISP encapsulation using destination UDP port
4341 [RFC6830]. 4341 [RFC6830].
skipping to change at page 36, line 14 skipping to change at page 36, line 8
6. Security Considerations 6. Security Considerations
There are no security considerations for this specification. The There are no security considerations for this specification. The
security considerations are documented for the protocols that use security considerations are documented for the protocols that use
LISP Canonical Addressing. LISP Canonical Addressing.
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. returned gratuitously. It is recommended to examine [RFC6280] and
[BCP160] architectures for location-based privacy protection.
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
skipping to change at page 37, line 9 skipping to change at page 36, line 48
| 12 | Source/Dest Key Type | Section 3 | | 12 | Source/Dest Key Type | Section 3 |
| 13 | Replication List Entry Type | Section 3 | | 13 | Replication List Entry Type | Section 3 |
+-------+------------------------------+------------+ +-------+------------------------------+------------+
Table 1: LISP LCAF Type Initial Values Table 1: LISP LCAF Type Initial Values
8. References 8. References
8.1. Normative References 8.1. Normative References
[BCP160] "An Architecture for Location and Location Privacy in
Internet Applications", Best Current Practices
https://www.rfc-editor.org/bcp/bcp160.txt, July 2011.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <http://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <http://www.rfc-editor.org/info/rfc3232>. January 2002, <http://www.rfc-editor.org/info/rfc3232>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011,
<http://www.rfc-editor.org/info/rfc6280>.
[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,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[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, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>. January 2013, <http://www.rfc-editor.org/info/rfc6836>.
skipping to change at page 38, line 8 skipping to change at page 38, line 13
<http://www.rfc-editor.org/info/rfc7348>. <http://www.rfc-editor.org/info/rfc7348>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network [RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation", Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015, RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>. <http://www.rfc-editor.org/info/rfc7637>.
8.2. Informative References 8.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/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007.
[I-D.coras-lisp-re] [I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 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-08 (work in progress), Engineering", draft-coras-lisp-re-08 (work in progress),
November 2015. November 2015.
[I-D.ermagan-lisp-nat-traversal] [I-D.ermagan-lisp-nat-traversal]
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", draft-ermagan- F., and C. White, "NAT traversal for LISP", draft-ermagan-
skipping to change at page 38, line 39 skipping to change at page 38, line 45
Generic Network Virtualization Encapsulation", draft- Generic Network Virtualization Encapsulation", draft-
gross-geneve-02 (work in progress), October 2014. gross-geneve-02 (work in progress), October 2014.
[I-D.herbert-gue] [I-D.herbert-gue]
Herbert, T., Yong, L., and O. Zia, "Generic UDP Herbert, T., Yong, L., and O. Zia, "Generic UDP
Encapsulation", draft-herbert-gue-03 (work in progress), Encapsulation", draft-herbert-gue-03 (work in progress),
March 2015. March 2015.
[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-08 (work in Confidentiality", draft-ietf-lisp-crypto-09 (work in
progress), September 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.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-
skipping to change at page 40, line 9 skipping to change at page 40, line 15
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.
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-17.txt B.1. Changes to draft-ietf-lisp-lcaf-18.txt
o Submitted October 2016 after October 13th telechat.
o Addressed comments from Ben Campbell, Jari Arrko, Stephen Farrel,
Peter Yee, Dale Worley, Mirja Kuehlewind, and Suresh Krishnan.
B.2. 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.2. Changes to draft-ietf-lisp-lcaf-16.txt B.3. 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.3. Changes to draft-ietf-lisp-lcaf-15.txt B.4. 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.4. Changes to draft-ietf-lisp-lcaf-14.txt B.5. 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.5. Changes to draft-ietf-lisp-lcaf-13.txt B.6. 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.6. Changes to draft-ietf-lisp-lcaf-12.txt B.7. 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.7. Changes to draft-ietf-lisp-lcaf-11.txt B.8. 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.8. Changes to draft-ietf-lisp-lcaf-10.txt B.9. 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.9. Changes to draft-ietf-lisp-lcaf-09.txt B.10. 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.10. Changes to draft-ietf-lisp-lcaf-08.txt B.11. 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.11. Changes to draft-ietf-lisp-lcaf-07.txt B.12. 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.12. Changes to draft-ietf-lisp-lcaf-06.txt B.13. 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.13. Changes to draft-ietf-lisp-lcaf-05.txt B.14. 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.14. Changes to draft-ietf-lisp-lcaf-04.txt B.15. 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.15. Changes to draft-ietf-lisp-lcaf-03.txt B.16. 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.16. Changes to draft-ietf-lisp-lcaf-02.txt B.17. 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.17. Changes to draft-ietf-lisp-lcaf-01.txt B.18. 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.18. Changes to draft-ietf-lisp-lcaf-00.txt B.19. 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
 End of changes. 55 change blocks. 
96 lines changed or deleted 108 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/