draft-ietf-lisp-08.txt   draft-ietf-lisp-09.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: February 14, 2011 D. Lewis Expires: April 14, 2011 D. Lewis
cisco Systems cisco Systems
August 13, 2010 October 11, 2010
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-08 draft-ietf-lisp-09
Abstract Abstract
This draft describes a network-based protocol that enables separation This draft describes a network-based protocol that enables separation
of IP addresses into two new numbering spaces: Endpoint Identifiers of IP addresses into two new numbering spaces: Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). No changes are required to (EIDs) and Routing Locators (RLOCs). No changes are required to
either host protocol stacks or to the "core" of the Internet either host protocol stacks or to the "core" of the Internet
infrastructure. LISP can be incrementally deployed, without a "flag infrastructure. LISP can be incrementally deployed, without a "flag
day", and offers traffic engineering, multi-homing, and mobility day", and offers traffic engineering, multi-homing, and mobility
benefits even to early adopters, when there are relatively few LISP- benefits even to early adopters, when there are relatively few LISP-
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 14, 2011. This Internet-Draft will expire on April 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 25 skipping to change at page 3, line 25
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 57 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 57
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 59 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 59
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 59 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 59
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 59 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 59
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 59 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 59
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 61 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 61
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 61 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 61
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 63 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 63
12. Security Considerations . . . . . . . . . . . . . . . . . . . 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 64
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
13.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 65
13.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 65
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14.1. Normative References . . . . . . . . . . . . . . . . . . . 66 14.1. Normative References . . . . . . . . . . . . . . . . . . . 66
14.2. Informative References . . . . . . . . . . . . . . . . . . 67 14.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 70
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 71 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 71
B.1. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 71 B.1. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 71
B.2. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 72 B.2. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 71
B.3. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 74 B.3. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 73
B.4. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 75 B.4. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 74
B.5. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 76 B.5. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 75
B.6. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 77 B.6. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 76
B.7. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 78 B.7. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 78
B.8. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 78 B.8. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 78
B.9. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 78 B.9. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79 B.10. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 79
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
skipping to change at page 20, line 22 skipping to change at page 20, line 22
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Status Bits | | Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E bit is the echo-nonce-request bit. When this bit is set to E: The E bit is the echo-nonce-request bit. When this bit is set to
1, the N bit MUST be 1. This bit SHOULD be ignored and has no 1, the N bit MUST be 1. This bit SHOULD be ignored and has no
meaning when the N bit is set to 0. See Section 6.3.1 for meaning when the N bit is set to 0. See Section 6.3.1 for
details. details.
V: The B bit is the Map-Version present bit. When this bit is set to V: The V bit is the Map-Version present bit. When this bit is set to
1, the N bit MUST be 0. Refer to Section 6.6.3 for more details. 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details.
This bit indicates that the first 4 bytes of the LISP header is This bit indicates that the first 4 bytes of the LISP header is
encoded as: encoded as:
0 x 0 1 x x x x 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator Status Bits | | Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 40 skipping to change at page 24, line 40
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
5.5. Using Virtualization and Segmentation with LISP 5.5. Using Virtualization and Segmentation with LISP
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-prefixes, their address spaces MUST remain addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI based address the address encoding can aid in making the entire AFI based address
unique. See [LCAF] for details for a possible address encoding. The unique. See IANA Considerations Section 13.1 for details for
LCAF encoding is an area for further study. possible address encodings.
An Instance ID can be carried in a LISP encapsulated packet. An ITR An Instance ID can be carried in a LISP encapsulated packet. An ITR
that prepends a LISP header, will copy a 24-bit value, used by the that prepends a LISP header, will copy a 24-bit value, used by the
LISP router to uniquely identify the address space. The value is LISP router to uniquely identify the address space. The value is
copied to the Instance ID field of the LISP header and the I-bit is copied to the Instance ID field of the LISP header and the I-bit is
set to 1. set to 1.
When an ETR decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup. to use for the inner destination EID lookup.
skipping to change at page 27, line 25 skipping to change at page 27, line 25
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LISP UDP-based messages are the Map-Request and Map-Reply The LISP UDP-based messages are the Map-Request and Map-Reply
messages. When a UDP Map-Request is sent, the UDP source port is messages. When a UDP Map-Request is sent, the UDP source port is
chosen by the sender and the destination UDP port number is set to chosen by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply is sent, the source UDP port number is 4342. When a UDP Map-Reply is sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking data packet.
Implementations MUST be prepared to accept packets when either the
source port or destination UDP port is set to 4342 due to NATs
changing port number values.
The UDP Length field will reflect the length of the UDP header and The UDP Length field will reflect the length of the UDP header and
the LISP Message payload. the LISP Message payload.
The UDP Checksum is computed and set to non-zero for Map-Request, The UDP Checksum is computed and set to non-zero for Map-Request,
Map-Reply, Map-Register and ECM control messages. It MUST be checked Map-Reply, Map-Register and ECM control messages. It MUST be checked
on receipt and if the checksum fails, the packet MUST be dropped. on receipt and if the checksum fails, the packet MUST be dropped.
LISP-CONS [CONS] uses TCP to send LISP control messages. The format LISP-CONS [CONS] uses TCP to send LISP control messages. The format
of control messages includes the UDP header so the checksum and of control messages includes the UDP header so the checksum and
skipping to change at page 50, line 20 skipping to change at page 50, line 20
The following procedure shows how a SMR exchange occurs when a site The following procedure shows how a SMR exchange occurs when a site
is doing locator-set compaction for an EID-to-RLOC mapping: is doing locator-set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site 1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each locator begin to send Map-Requests with the SMR bit set for each locator
in each map-cache entry the ETR caches. in each map-cache entry the ETR caches.
2. A remote ITR which receives the SMR message will schedule sending 2. A remote ITR which receives the SMR message will schedule sending
a Map-Request message to the source locator address of the SMR a Map-Request message to the source locator address of the SMR
message. A newly allocated random nonce is selected and the EID- message or to the mapping database system. A newly allocated
prefix used is the one copied from the SMR message. If the random nonce is selected and the EID-prefix used is the one
source locator is the only locator in the cached locator-set, the copied from the SMR message. If the source locator is the only
remote ITR SHOULD send a Map-Request to the database mapping locator in the cached locator-set, the remote ITR SHOULD send a
system just in case the single locator has changed and may no Map-Request to the database mapping system just in case the
longer be reachable to accept the Map-Request. single locator has changed and may no longer be reachable to
accept the Map-Request.
3. The remote ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request until it gets a
Map-Reply while continuing to use the cached mapping. When Map Map-Reply while continuing to use the cached mapping. When Map
Versioning is used, described in Section 6.6.3, an SMR sender can Versioning is used, described in Section 6.6.3, an SMR sender can
detect if an ITR is using the most up to date database mapping. detect if an ITR is using the most up to date database mapping.
4. The ETRs at the site with the changed mapping will reply to the 4. The ETRs at the site with the changed mapping will reply to the
Map-Request with a Map-Reply message that has a nonce from the Map-Request with a Map-Reply message that has a nonce from the
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate
limited. This is important to avoid Map-Reply implosion. limited. This is important to avoid Map-Reply implosion.
skipping to change at page 51, line 5 skipping to change at page 51, line 6
For security reasons an ITR MUST NOT process unsolicited Map-Replies. For security reasons an ITR MUST NOT process unsolicited Map-Replies.
To avoid map-cache entry corruption by a third-party, a sender of an To avoid map-cache entry corruption by a third-party, a sender of an
SMR-based Map-Request MUST be verified. If an ITR receives an SMR- SMR-based Map-Request MUST be verified. If an ITR receives an SMR-
based Map-Request and the source is not in the locator-set for the based Map-Request and the source is not in the locator-set for the
stored map-cache entry, then the responding Map-Request MUST be sent stored map-cache entry, then the responding Map-Request MUST be sent
with an EID destination to the mapping database system. Since the with an EID destination to the mapping database system. Since the
mapping database system is more secure to reach an authoritative ETR, mapping database system is more secure to reach an authoritative ETR,
it will deliver the Map-Request to the authoritative source of the it will deliver the Map-Request to the authoritative source of the
mapping data. mapping data.
When an ITR receives an SMR-based Map-Request for which it does not
have a cached mapping for the EID in the SMR message, it MAY not send
a SMR-invoked Map-Request. This scenario can occur when an ETR sends
SMR messages to all locators in the locator-set it has stored in its
map-cache but the remote ITRs that receive the SMR may not be sending
packets to the site. There is no point in updating the ITRs until
they need to send, in which case, they will send Map-Requests to
obtain a map-cache entry.
6.6.3. Database Map Versioning 6.6.3. Database Map Versioning
When there is unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an ITR and ETR, and
the EID-to-RLOC mappings change on the ETR, it needs to inform the the EID-to-RLOC mappings change on the ETR, it needs to inform the
ITR so encapsulation can stop to a removed locator and start to a new ITR so encapsulation can stop to a removed locator and start to a new
locator in the locator-set. locator in the locator-set.
An ETR, when it sends Map-Reply messages, conveys its own Map-Version An ETR, when it sends Map-Reply messages, conveys its own Map-Version
number. This is known as the Destination Map-Version Number. ITRs number. This is known as the Destination Map-Version Number. ITRs
include the Destination Map-Version Number in packets they include the Destination Map-Version Number in packets they
skipping to change at page 65, line 7 skipping to change at page 65, line 7
limiting the number of data-triggered Map-Replies. limiting the number of data-triggered Map-Replies.
To deal with map-cache exhaustion attempts in an ITR/PTR, the To deal with map-cache exhaustion attempts in an ITR/PTR, the
implementation should consider putting a maximum cap on the number of implementation should consider putting a maximum cap on the number of
entries stored with a reserve list for special or frequently accessed entries stored with a reserve list for special or frequently accessed
sites. This should be a configuration policy control set by the sites. This should be a configuration policy control set by the
network administrator who manages ITRs and PTRs. network administrator who manages ITRs and PTRs.
13. IANA Considerations 13. IANA Considerations
This specification has already allocated UDP port numbers 4341 and This section provides guidance to the Internet Assigned Numbers
4342 assigned from the IANA registry. Authority (IANA) regarding registration of values related to the LISP
specification, in accordance with BCP 26 and RFC 5226 [RFC5226].
There are two name spaces in LISP that require registration:
o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Consensus", "Experimental
Use", "First Come First Served".
13.1. LISP Address Type Codes
Instance ID type codes have a range from 0 to 15, of which 0 and 1
have been allocated [LCAF]. New Type Codes MUST be allocated
starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review.
Type Codes 11 - 15 are available on a First Come First Served policy.
The following codes have been allocated:
Type 0: Null Body Type
Type 1: AFI List Type
See [LCAF] for details for other possible unapproved address
encodings. The unapproved LCAF encodings are an area for further
study and experimentation.
13.2. LISP UDP Port Numbers
The IANA registry has allocated UDP port numbers 4341 and 4342 for
LISP data-plane and control-plane operation, respectively.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
skipping to change at page 68, line 9 skipping to change at page 68, line 9
draft-curran-lisp-emacs-00.txt (work in progress), draft-curran-lisp-emacs-00.txt (work in progress),
November 2007. November 2007.
[INTERWORK] [INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-01.txt (work in progress), draft-ietf-lisp-interworking-01.txt (work in progress),
March 2010. March 2010.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-farinacci-lisp-lcaf-00.txt (work in Address Format", draft-farinacci-lisp-lcaf-02.txt (work in
progress), April 2010. progress), October 2010.
[LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
"Renumbering: Threat or Menace?", Usenix , September 1996. "Renumbering: Threat or Menace?", Usenix , September 1996.
[LISP-MAIN] [LISP-MAIN]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12.txt (work in progress), draft-farinacci-lisp-12.txt (work in progress),
March 2009. March 2009.
[LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-03.txt (work Mobility Architecture", draft-meyer-lisp-mn-05.txt (work
in progress), August 2010. in progress), October 2010.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-05.txt (work in progress), April 2010. draft-ietf-lisp-ms-05.txt (work in progress), April 2010.
[LOC-ID-ARCH] [LOC-ID-ARCH]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Locator/ID Separation",
draft-meyer-loc-id-implications-01.txt (work in progress), draft-meyer-loc-id-implications-01.txt (work in progress),
Januaryr 2009. Januaryr 2009.
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-03.txt (work in progress), draft-ietf-lisp-multicast-04.txt (work in progress),
April 2010. October 2010.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08.txt (work in progress), draft-lear-lisp-nerd-08.txt (work in progress),
March 2010. March 2010.
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
Report", draft-iannone-openlisp-implementation-01.txt Report", draft-iannone-openlisp-implementation-01.txt
(work in progress), July 2008. (work in progress), July 2008.
skipping to change at page 69, line 21 skipping to change at page 69, line 21
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
for Routing Protocol Meta-data Dissemination", for Routing Protocol Meta-data Dissemination",
draft-handley-p2ppush-unpublished-2007726.txt (work in draft-handley-p2ppush-unpublished-2007726.txt (work in
progress), July 2007. progress), July 2007.
[VERSIONING] [VERSIONING]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
Versioning", draft-iannone-lisp-mapping-versioning-01.txt Versioning", draft-iannone-lisp-mapping-versioning-02.txt
(work in progress), March 2010. (work in progress), July 2010.
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed review of the LISP of location and identity, as well as detailed review of the LISP
skipping to change at page 71, line 7 skipping to change at page 71, line 7
Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, and Vina Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, and Vina
Ermagan. Ermagan.
This work originated in the Routing Research Group (RRG) of the IRTF. This work originated in the Routing Research Group (RRG) of the IRTF.
The individual submission [LISP-MAIN] was converted into this IETF The individual submission [LISP-MAIN] was converted into this IETF
LISP working group draft. LISP working group draft.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-08.txt B.1. Changes to draft-ietf-lisp-09.txt
o Posted October 2010.
o Add to IANA Consideration section about the use of LCAF Type
values that accepted and maintained by the IANA registry and not
the LCAF specification.
o Indicate that implementations should be able to receive LISP
control messages when either UDP port is 4342, so they can be
robust in the face of intervening NAT boxes.
o Add paragraph to SMR section to indicate that an ITR does not need
to respond to an SMR-based Map-Request when it has no map-cache
entry for the SMR source's EID-prefix.
B.2. Changes to draft-ietf-lisp-08.txt
o Posted August 2010. o Posted August 2010.
o In section 6.1.6, remove statement about setting TTL to 0 in Map- o In section 6.1.6, remove statement about setting TTL to 0 in Map-
Register messages. Register messages.
o Clarify language in section 6.1.5 about Map-Replying to Data- o Clarify language in section 6.1.5 about Map-Replying to Data-
Probes or Map-Requests. Probes or Map-Requests.
o Indicate that outer TTL should only be copied to inner TTL when it o Indicate that outer TTL should only be copied to inner TTL when it
skipping to change at page 72, line 42 skipping to change at page 73, line 11
o Remove text on copying nonce from SMR to SMR-invoked Map- Request o Remove text on copying nonce from SMR to SMR-invoked Map- Request
per Vina's comment about a possible DoS vector. per Vina's comment about a possible DoS vector.
o Clarify (S/2 + H) in the stateless MTU section. o Clarify (S/2 + H) in the stateless MTU section.
o Add text to reflect Damien's comment about the description of the o Add text to reflect Damien's comment about the description of the
"ITR-RLOC Address" field in the Map-Request. that the list of RLOC "ITR-RLOC Address" field in the Map-Request. that the list of RLOC
addresses are local addresses of the Map-Requester. addresses are local addresses of the Map-Requester.
B.2. Changes to draft-ietf-lisp-07.txt B.3. Changes to draft-ietf-lisp-07.txt
o Posted April 2010. o Posted April 2010.
o Added I-bit to data header so LSB field can also be used as an o Added I-bit to data header so LSB field can also be used as an
Instance ID field. When this occurs, the LSB field is reduced to Instance ID field. When this occurs, the LSB field is reduced to
8-bits (from 32-bits). 8-bits (from 32-bits).
o Added V-bit to the data header so the 24-bit nonce field can also o Added V-bit to the data header so the 24-bit nonce field can also
be used for source and destination version numbers. be used for source and destination version numbers.
skipping to change at page 74, line 17 skipping to change at page 74, line 34
o In section 9.2, add text to describe what the signature of o In section 9.2, add text to describe what the signature of
traceroute packets can look like. traceroute packets can look like.
o Removed references to Data Probe for introductory example. Data- o Removed references to Data Probe for introductory example. Data-
probes are still part of the LISP design but not encouraged. probes are still part of the LISP design but not encouraged.
o Added the definition for "LISP site" to the Definition of Terms" o Added the definition for "LISP site" to the Definition of Terms"
section. section.
B.3. Changes to draft-ietf-lisp-06.txt B.4. Changes to draft-ietf-lisp-06.txt
Editorial based changes: Editorial based changes:
o Posted December 2009. o Posted December 2009.
o Fix typo for flags in LISP data header. Changed from "4" to "5". o Fix typo for flags in LISP data header. Changed from "4" to "5".
o Add text to indicate that Map-Register messages must contain a o Add text to indicate that Map-Register messages must contain a
computed UDP checksum. computed UDP checksum.
skipping to change at page 75, line 26 skipping to change at page 75, line 43
These type of Map-Requests are used as RLOC-probes and are sent These type of Map-Requests are used as RLOC-probes and are sent
directly to locator addresses in the underlying network. directly to locator addresses in the underlying network.
o Add text in section 6.1.5 about returning all EID-prefixes in a o Add text in section 6.1.5 about returning all EID-prefixes in a
Map-Reply sent by an ETR when there are overlapping EID-prefixes Map-Reply sent by an ETR when there are overlapping EID-prefixes
configure. configure.
o Add text in a new subsection of section 6.1.5 about dealing with o Add text in a new subsection of section 6.1.5 about dealing with
Map-Replies with coarse EID-prefixes. Map-Replies with coarse EID-prefixes.
B.4. Changes to draft-ietf-lisp-05.txt B.5. Changes to draft-ietf-lisp-05.txt
o Posted September 2009. o Posted September 2009.
o Added this Document Change Log appendix. o Added this Document Change Log appendix.
o Added section indicating that encapsulated Map-Requests must use o Added section indicating that encapsulated Map-Requests must use
destination UDP port 4342. destination UDP port 4342.
o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- o Don't use AH in Map-Registers. Put key-id, auth-length, and auth-
data in Map-Register payload. data in Map-Register payload.
skipping to change at page 76, line 5 skipping to change at page 76, line 24
o The LISP-CONS authors thought that the Type definitions for CONS o The LISP-CONS authors thought that the Type definitions for CONS
should be removed from this specification. should be removed from this specification.
o Removed nonce from Map-Register message, it wasn't used so no need o Removed nonce from Map-Register message, it wasn't used so no need
for it. for it.
o Clarify what to do for unspecified Action bits for negative Map- o Clarify what to do for unspecified Action bits for negative Map-
Replies. Since No Action is a drop, make value 0 Drop. Replies. Since No Action is a drop, make value 0 Drop.
B.5. Changes to draft-ietf-lisp-04.txt B.6. Changes to draft-ietf-lisp-04.txt
o Posted September 2009. o Posted September 2009.
o How do deal with record count greater than 1 for a Map-Request. o How do deal with record count greater than 1 for a Map-Request.
Damien and Joel comment. Joel suggests: 1) Specify that senders Damien and Joel comment. Joel suggests: 1) Specify that senders
compliant with the current document will always set the count to compliant with the current document will always set the count to
1, and note that the count is included for future extensibility. 1, and note that the count is included for future extensibility.
2) Specify what a receiver compliant with the draft should do if 2) Specify what a receiver compliant with the draft should do if
it receives a request with a count greater than 1. Presumably, it it receives a request with a count greater than 1. Presumably, it
should send some error back? should send some error back?
skipping to change at page 77, line 44 skipping to change at page 78, line 15
o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Reference IPsec RFC 4302. Comment from Sam and Brian Weis.
o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
noncing. Comment by Pedro and Dino. noncing. Comment by Pedro and Dino.
o Jesper made a comment to loosen the language about requiring the o Jesper made a comment to loosen the language about requiring the
copy of inner TTL to outer TTL since the text to get mixed-AF copy of inner TTL to outer TTL since the text to get mixed-AF
traceroute to work would violate the "MUST" clause. Changed from traceroute to work would violate the "MUST" clause. Changed from
MUST to SHOULD in section 5.3. MUST to SHOULD in section 5.3.
B.6. Changes to draft-ietf-lisp-03.txt B.7. Changes to draft-ietf-lisp-03.txt
o Posted July 2009. o Posted July 2009.
o Removed loc-reach-bits longword from control packets per Damien o Removed loc-reach-bits longword from control packets per Damien
comment. comment.
o Clarifications in MTU text from Roque. o Clarifications in MTU text from Roque.
o Added text to indicate that the locator-set be sorted by locator o Added text to indicate that the locator-set be sorted by locator
address from Isidor. address from Isidor.
o Clarification text from John Zwiebel in Echo-Nonce section. o Clarification text from John Zwiebel in Echo-Nonce section.
B.7. Changes to draft-ietf-lisp-02.txt B.8. Changes to draft-ietf-lisp-02.txt
o Posted July 2009. o Posted July 2009.
o Encapsulation packet format change to add E-bit and make loc- o Encapsulation packet format change to add E-bit and make loc-
reach-bits 32-bits in length. reach-bits 32-bits in length.
o Added Echo-Nonce Algorithm section. o Added Echo-Nonce Algorithm section.
o Clarification how ECN bits are copied. o Clarification how ECN bits are copied.
o Moved S-bit in Map-Request. o Moved S-bit in Map-Request.
o Added P-bit in Map-Request and Map-Reply messages to anticipate o Added P-bit in Map-Request and Map-Reply messages to anticipate
RLOC-Probe Algorithm. RLOC-Probe Algorithm.
o Added to Mobility section to reference [LISP-MN]. o Added to Mobility section to reference [LISP-MN].
B.8. Changes to draft-ietf-lisp-01.txt B.9. Changes to draft-ietf-lisp-01.txt
o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Posted 2 days after draft-ietf-lisp-00.txt in May 2009.
o Defined LEID to be a "LISP EID". o Defined LEID to be a "LISP EID".
o Indicate encapsulation use IPv4 DF=0. o Indicate encapsulation use IPv4 DF=0.
o Added negative Map-Reply messages with drop, native-forward, and o Added negative Map-Reply messages with drop, native-forward, and
send-map-request actions. send-map-request actions.
o Added Proxy-Map-Reply bit to Map-Register. o Added Proxy-Map-Reply bit to Map-Register.
B.9. Changes to draft-ietf-lisp-00.txt B.10. Changes to draft-ietf-lisp-00.txt
o Posted May 2009. o Posted May 2009.
o Rename of draft-farinacci-lisp-12.txt. o Rename of draft-farinacci-lisp-12.txt.
o Acknowledgment to RRG. o Acknowledgment to RRG.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
 End of changes. 25 change blocks. 
42 lines changed or deleted 106 lines changed or added

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