draft-ietf-lisp-14.txt   draft-ietf-lisp-15.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: December 31, 2011 D. Lewis Expires: January 10, 2012 D. Lewis
cisco Systems cisco Systems
June 29, 2011 July 9, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-14 draft-ietf-lisp-15
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-
capable sites. capable sites.
Design and development of LISP was largely motivated by the problem Design and development of LISP was largely motivated by the problem
statement produced by the October, 2006 IAB Routing and Addressing statement produced by the October, 2006 IAB Routing and Addressing
Workshop. Workshop.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 10, 2012.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17
skipping to change at page 3, line 33 skipping to change at page 3, line 28
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67
12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68
13. Network Management Considerations . . . . . . . . . . . . . . 70 13. Network Management Considerations . . . . . . . . . . . . . . 70
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71
14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1. Normative References . . . . . . . . . . . . . . . . . . . 72 15.1. Normative References . . . . . . . . . . . . . . . . . . . 72
15.2. Informative References . . . . . . . . . . . . . . . . . . 73 15.2. Informative References . . . . . . . . . . . . . . . . . . 73
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 76
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 77
B.1. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 78 B.1. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 77
B.2. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 78 B.2. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 77
B.3. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 79 B.3. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 77
B.4. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 80 B.4. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 78
B.5. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 81 B.5. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 79
B.6. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81 B.6. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 80
B.7. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 82 B.7. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81
B.8. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 84 B.8. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 81
B.9. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 85 B.9. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 83
B.10. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 86 B.10. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 84
B.11. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 87 B.11. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 85
B.12. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 89 B.12. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 86
B.13. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 89 B.13. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 88
B.14. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89 B.14. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 88
B.15. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 90 B.15. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91 B.16. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
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 10, line 30 skipping to change at page 10, line 30
statically configured. When using multiple mapping database statically configured. When using multiple mapping database
systems, care must be taken to not create reencapsulation loops. systems, care must be taken to not create reencapsulation loops.
LISP Header: a term used in this document to refer to the outer LISP Header: a term used in this document to refer to the outer
IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
header that follows the UDP header, an ITR prepends or an ETR header that follows the UDP header, an ITR prepends or an ETR
strips. strips.
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. An address family currently pertains to an encoding in a packet. An address family currently pertains to an
IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC1700] for IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC3232] for
details. An AFI value of 0 used in this specification indicates details. An AFI value of 0 used in this specification indicates
an unspecified encoded address where the length of the address is an unspecified encoded address where the length of the address is
0 bytes following the 16-bit AFI value of 0. 0 bytes following the 16-bit AFI value of 0.
Negative Mapping Entry: A negative mapping entry, also known as a Negative Mapping Entry: A negative mapping entry, also known as a
negative cache entry, is an EID-to-RLOC entry where an EID-prefix negative cache entry, is an EID-to-RLOC entry where an EID-prefix
is advertised or stored with no RLOCs. That is, the locator-set is advertised or stored with no RLOCs. That is, the locator-set
for the EID-to-RLOC entry is empty or has an encoded locator count for the EID-to-RLOC entry is empty or has an encoded locator count
of 0. This type of entry could be used to describe a prefix from of 0. This type of entry could be used to describe a prefix from
a non-LISP site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the mapping database.
skipping to change at page 14, line 10 skipping to change at page 14, line 10
could be the site's border router at the service provider attachment could be the site's border router at the service provider attachment
point. Mixing and matching of site-operated, ISP-operated, and other point. Mixing and matching of site-operated, ISP-operated, and other
tunnel routers is allowed for maximum flexibility. See Section 8 for tunnel routers is allowed for maximum flexibility. See Section 8 for
more details. more details.
4.1. Packet Flow Sequence 4.1. Packet Flow Sequence
This section provides an example of the unicast packet flow with the This section provides an example of the unicast packet flow with the
following conditions: following conditions:
o Source host "host1.abc.com" is sending a packet to o Source host "host1.example.abc.com" is sending a packet to
"host2.xyz.com", exactly what host1 would do if the site was not "host2.example.xyz.com", exactly what host1 would do if the site
using LISP. was not using LISP.
o Each site is multi-homed, so each tunnel router has an address o Each site is multi-homed, so each tunnel router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular tunnel router is attached. provider to which that particular tunnel router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively, but the source and destination can be destination, respectively, but the source and destination can be
located anywhere in LISP site. located anywhere in LISP site.
o Map-Requests can be sent on the underlying routing system topology o Map-Requests can be sent on the underlying routing system topology
or over an alternative topology [ALT]. or over an alternative topology [ALT].
o Map-Replies are sent on the underlying routing system topology. o Map-Replies are sent on the underlying routing system topology.
Client host1.abc.com wants to communicate with server host2.xyz.com: Client host1.example.abc.com wants to communicate with server
host2.example.xyz.com:
1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 1. host1.example.abc.com wants to open a TCP connection to
It does a DNS lookup on host2.xyz.com. An A/AAAA record is host2.example.xyz.com. It does a DNS lookup on
returned. This address is the destination EID. The locally- host2.example.xyz.com. An A/AAAA record is returned. This
assigned address of host1.abc.com is used as the source EID. An address is the destination EID. The locally-assigned address of
IPv4 or IPv6 packet is built and forwarded through the LISP site host1.example.abc.com is used as the source EID. An IPv4 or IPv6
as a normal IP packet until it reaches a LISP ITR. packet is built and forwarded through the LISP site as a normal
IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the EID destination to an RLOC 2. The LISP ITR must be able to map the EID destination to an RLOC
of one of the ETRs at the destination site. The specific method of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See [ALT] or used to do this is not described in this example. See [ALT] or
[CONS] for possible solutions. [CONS] for possible solutions.
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
rate-limited. rate-limited.
4. When an alternate mapping system is not in use, the Map-Request 4. When an alternate mapping system is not in use, the Map-Request
skipping to change at page 15, line 16 skipping to change at page 15, line 19
the Map-Request is dropped. Otherwise, a LISP Map-Reply is the Map-Request is dropped. Otherwise, a LISP Map-Reply is
returned to the ITR. returned to the ITR.
6. The ITR receives the Map-Reply message, parses the message (to 6. The ITR receives the Map-Reply message, parses the message (to
check for format validity) and stores the mapping information check for format validity) and stores the mapping information
from the packet. This information is stored in the ITR's EID-to- from the packet. This information is stored in the ITR's EID-to-
RLOC mapping cache. Note that the map cache is an on-demand RLOC mapping cache. Note that the map cache is an on-demand
cache. An ITR will manage its map cache in such a way that cache. An ITR will manage its map cache in such a way that
optimizes for its resource constraints. optimizes for its resource constraints.
7. Subsequent packets from host1.abc.com to host2.xyz.com will have 7. Subsequent packets from host1.example.abc.com to
a LISP header prepended by the ITR using the appropriate RLOC as host2.example.xyz.com will have a LISP header prepended by the
the LISP header destination address learned from the ETR. Note ITR using the appropriate RLOC as the LISP header destination
the packet may be sent to a different ETR than the one which address learned from the ETR. Note the packet may be sent to a
returned the Map-Reply due to the source site's hashing policy or different ETR than the one which returned the Map-Reply due to
the destination site's locator-set policy. the source site's hashing policy or the destination site's
locator-set policy.
8. The ETR receives these packets directly (since the destination 8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), strips the LISP address is one of its assigned IP addresses), strips the LISP
header and forwards the packets to the attached destination host. header and forwards the packets to the attached destination host.
In order to defer the need for a mapping lookup in the reverse In order to defer the need for a mapping lookup in the reverse
direction, an ETR MAY create a cache entry that maps the source EID direction, an ETR MAY create a cache entry that maps the source EID
(inner header source IP address) to the source RLOC (outer header (inner header source IP address) to the source RLOC (outer header
source IP address) in a received LISP packet. Such a cache entry is source IP address) in a received LISP packet. Such a cache entry is
termed a "gleaned" mapping and only contains a single RLOC for the termed a "gleaned" mapping and only contains a single RLOC for the
skipping to change at page 40, line 27 skipping to change at page 40, line 27
the Authentication Data field is dependent on the Message the Authentication Data field is dependent on the Message
Authentication Code (MAC) algorithm used. The length field allows Authentication Code (MAC) algorithm used. The length field allows
a device that doesn't know the MAC algorithm to correctly parse a device that doesn't know the MAC algorithm to correctly parse
the packet. the packet.
Authentication Data: The message digest used from the output of the Authentication Data: The message digest used from the output of the
Message Authentication Code (MAC) algorithm. The entire Map- Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0. Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field. After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC6234]
is recommended. is recommended.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section.
6.1.7. Map-Notify Message Format 6.1.7. Map-Notify Message Format
The usage details of the Map-Notify message can be found in The usage details of the Map-Notify message can be found in
specification [LISP-MS]. This section solely defines the message specification [LISP-MS]. This section solely defines the message
format. format.
skipping to change at page 44, line 47 skipping to change at page 44, line 47
source address) of the received encapsulated packet. A reply to source address) of the received encapsulated packet. A reply to
this "verifying Map-Request" is used to fully populate the map- this "verifying Map-Request" is used to fully populate the map-
cache entry for the "gleaned" EID and is stored and used for the cache entry for the "gleaned" EID and is stored and used for the
time indicated from the TTL field of a received Map-Reply. When a time indicated from the TTL field of a received Map-Reply. When a
verified map-cache entry is stored, data gleaning no longer occurs verified map-cache entry is stored, data gleaning no longer occurs
for subsequent packets which have a source EID that matches the for subsequent packets which have a source EID that matches the
EID-prefix of the verified entry. EID-prefix of the verified entry.
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
reachable when the R-bit for the locator record is set to 1. When reachable when the R-bit for the locator record is set to 1. When
the R-bit is set to 0, an ITR or PITR MUST not encapsulate to the the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the
RLOC. Neither the information contained in a Map-Reply or that RLOC. Neither the information contained in a Map-Reply or that
stored in the mapping database system provides reachability stored in the mapping database system provides reachability
information for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not part of the
mapping system and is determined using one or more of the Routing mapping system and is determined using one or more of the Routing
Locator Reachability Algorithms described in the next section. Locator Reachability Algorithms described in the next section.
6.3. Routing Locator Reachability 6.3. Routing Locator Reachability
Several mechanisms for determining RLOC reachability are currently Several mechanisms for determining RLOC reachability are currently
defined: defined:
skipping to change at page 49, line 8 skipping to change at page 49, line 8
from one of its own locator addresses. A Map-Request used as an from one of its own locator addresses. A Map-Request used as an
RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
ALT like one would when soliciting mapping data. The EID record ALT like one would when soliciting mapping data. The EID record
encoded in the Map-Request is the EID-prefix of the map-cache entry encoded in the Map-Request is the EID-prefix of the map-cache entry
cached by the ITR or PTR. The ITR may include a mapping data record cached by the ITR or PTR. The ITR may include a mapping data record
for its own database mapping information which contains the local for its own database mapping information which contains the local
EID-prefixes and RLOCs for its site. EID-prefixes and RLOCs for its site.
When an ETR receives a Map-Request message with the probe-bit set, it When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set from the destination address of the Map-Request the Map-Reply is set according to the procedure described in
and the destination address of the Map-Reply is set from the source Section 6.1.5. The Map-Reply SHOULD contain mapping data for the
address of the Map-Request. The Map-Reply SHOULD contain mapping EID-prefix contained in the Map-Request. This provides the
data for the EID-prefix contained in the Map-Request. This provides opportunity for the ITR or PTR, which sent the RLOC-probe to get
the opportunity for the ITR or PTR, which sent the RLOC-probe to get
mapping updates if there were changes to the ETR's database mapping mapping updates if there were changes to the ETR's database mapping
entries. entries.
There are advantages and disadvantages of RLOC Probing. The greatest There are advantages and disadvantages of RLOC Probing. The greatest
benefit of RLOC Probing is that it can handle many failure scenarios benefit of RLOC Probing is that it can handle many failure scenarios
allowing the ITR to determine when the path to a specific locator is allowing the ITR to determine when the path to a specific locator is
reachable or has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a robust
mechanism for switching to using another locator from the cached mechanism for switching to using another locator from the cached
locator. RLOC Probing can also provide rough RTT estimates between a locator. RLOC Probing can also provide rough RTT estimates between a
pair of locators which can be useful for network management purposes pair of locators which can be useful for network management purposes
skipping to change at page 63, line 30 skipping to change at page 63, line 30
maintaining session continuity. Renumbering is involved. LISP can maintaining session continuity. Renumbering is involved. LISP can
help with the issues surrounding renumbering [RFC4192] [LISA96] by help with the issues surrounding renumbering [RFC4192] [LISA96] by
decoupling the address space used by a site from the address spaces decoupling the address space used by a site from the address spaces
used by its ISPs. [RFC4984] used by its ISPs. [RFC4984]
10.3. Fast Endpoint Mobility 10.3. Fast Endpoint Mobility
Fast endpoint mobility occurs when an endpoint moves relatively Fast endpoint mobility occurs when an endpoint moves relatively
rapidly, changing its IP layer network attachment point. Maintenance rapidly, changing its IP layer network attachment point. Maintenance
of session continuity is a goal. This is where the Mobile IPv4 of session continuity is a goal. This is where the Mobile IPv4
[RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, [RFC5944] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used,
and primarily where interactions with LISP need to be explored. and primarily where interactions with LISP need to be explored.
The problem is that as an endpoint moves, it may require changes to The problem is that as an endpoint moves, it may require changes to
the mapping between its EID and a set of RLOCs for its new network the mapping between its EID and a set of RLOCs for its new network
location. When this is added to the overhead of mobile IP binding location. When this is added to the overhead of mobile IP binding
updates, some packets might be delayed or dropped. updates, some packets might be delayed or dropped.
In IPv4 mobility, when an endpoint is away from home, packets to it In IPv4 mobility, when an endpoint is away from home, packets to it
are encapsulated and forwarded via a home agent which resides in the are encapsulated and forwarded via a home agent which resides in the
home area the endpoint's address belongs to. The home agent will home area the endpoint's address belongs to. The home agent will
skipping to change at page 72, line 24 skipping to change at page 72, line 24
Routing Protocols (KARP)Design Guidelines", Routing Protocols (KARP)Design Guidelines",
draft-ietf-karp-design-guide-02.txt (work in progress), draft-ietf-karp-design-guide-02.txt (work in progress),
March 2011. March 2011.
[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.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
skipping to change at page 72, line 48 skipping to change at page 72, line 45
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
[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,
May 2008. May 2008.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RPKI] Lepinski, M., "An Infrastructure to Support Secure [RPKI] Lepinski, M., "An Infrastructure to Support Secure
Internet Routing", draft-ietf-sidr-arch-12.txt (work in Internet Routing", draft-ietf-sidr-arch-13.txt (work in
progress), February 2011. progress), February 2011.
[UDP-TUNNELS] [UDP-TUNNELS]
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
Packets", draft-eubanks-chimento-6man-01.txt (work in Packets", draft-eubanks-chimento-6man-01.txt (work in
progress), October 2010. progress), October 2010.
15.2. Informative References 15.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS NUMBERS
http://www.iana.org/assignments/address-family-numbers, http://www.iana.org/assignments/address-family-numbers.
January 2011.
[AFI-REGISTRY] [AFI-REGISTRY]
IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBER registry http://www.iana.org/assignments/ NUMBER registry http://www.iana.org/assignments/
address-family-numbers/ address-family-numbers/
address-family-numbers.xml#address-family-numbers-1, address-family-numbers.xml#address-family-numbers-1.
January 2011.
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-07.txt (work in progress), June 2011. draft-ietf-lisp-alt-07.txt (work in progress).
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed
Enhancement to the Internet Architecture", Internet- Enhancement to the Internet Architecture", Internet-
Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, Draft http://www.chiappa.net/~jnc/tech/endpoints.txt.
1999.
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-03.txt (work in progress), draft-meyer-lisp-cons-04.txt (work in progress).
November 2007.
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00.txt (work in progress), draft-curran-lisp-emacs-00.txt (work in progress).
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-02.txt (work in progress), draft-ietf-lisp-interworking-02.txt (work in progress).
June 2011.
[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-04.txt (work in Address Format", draft-farinacci-lisp-lcaf-05.txt (work in
progress), October 2010. progress).
[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 .
[LISP-DEPLOY] [LISP-DEPLOY]
Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis,
"LISP Network Element Deployment Considerations", "LISP Network Element Deployment Considerations",
draft-jakab-lisp-deployment-02.txt (work in progress), draft-jakab-lisp-deployment-03.txt (work in progress).
February 2011.
[LISP-LIG] [LISP-LIG]
Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-ietf-lisp-lig-01.txt (work in progress), draft-ietf-lisp-lig-02.txt (work in progress).
October 2010.
[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.
[LISP-MIB] [LISP-MIB]
Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
draft-ietf-lisp-mib-01.txt (work in progress), March 2011. draft-ietf-lisp-mib-02.txt (work in progress).
[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-04.txt (work Mobility Architecture", draft-meyer-lisp-mn-05.txt (work
in progress), October 2010. in progress).
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-09.txt (work in progress), June 2011. draft-ietf-lisp-ms-09.txt (work in progress).
[LISP-SEC] [LISP-SEC]
Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
Bonaventure, "LISP-Security (LISP-SEC)", Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-00.txt (work in progress), June 2011. draft-ietf-lisp-sec-00.txt (work in progress).
[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.
[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-06.txt (work in progress), draft-ietf-lisp-multicast-06.txt (work in progress).
June 2011.
[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.
[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-02.txt
(work in progress), July 2008. (work in progress).
[RADIR] Narten, T., "Routing and Addressing Problem Statement", [RADIR] Narten, T., "Routing and Addressing Problem Statement",
draft-narten-radir-problem-statement-00.txt (work in draft-narten-radir-problem-statement-05.txt (work in
progress), July 2007. progress).
[RFC3344bis]
Perkins, C., "IP Mobility Support for IPv4, revised",
draft-ietf-mip4-rfc3344bis-05 (work in progress),
July 2007.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
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).
[VERSIONING] [VERSIONING]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
Versioning", draft-ietf-lisp-map-versioning-01.txt (work Versioning", draft-ietf-lisp-map-versioning-01.txt (work
in progress), March 2011. in progress).
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 78, line 7 skipping to change at page 77, line 7
Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White,
Clarence Filsfils, and Alia Atlas. Clarence Filsfils, and Alia Atlas.
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-14.txt B.1. Changes to draft-ietf-lisp-15.txt
o Posted July 2011. Fixing IDnits errors.
o Change description on how to select a source address for RLOC-
probe Map-Replies to refer to the "EID-to-RLOC Map-Reply Message"
section.
B.2. Changes to draft-ietf-lisp-14.txt
o Post working group last call and pre-IESG last call review. o Post working group last call and pre-IESG last call review.
o Indicate that an ICMP Unreachable message should be sent when a o Indicate that an ICMP Unreachable message should be sent when a
packet matches a drop-based negative map-cache entry. packet matches a drop-based negative map-cache entry.
o Indicate how a map-cache set of overlapping EID-prefixes must o Indicate how a map-cache set of overlapping EID-prefixes must
maintian integrity when the map-cache maximum cap is reached. maintian integrity when the map-cache maximum cap is reached.
o Add Joel's description for the definition of an EID, that the bit o Add Joel's description for the definition of an EID, that the bit
skipping to change at page 78, line 37 skipping to change at page 77, line 45
in the Data Probe definition section. in the Data Probe definition section.
o Added text indicating that more-specific EID-prefixes must not be o Added text indicating that more-specific EID-prefixes must not be
removed when less-specific entries stay in the map-cache. This is removed when less-specific entries stay in the map-cache. This is
to preserve the integrity of the EID-prefix set. to preserve the integrity of the EID-prefix set.
o Add clarifying text in the Security Considerations section about o Add clarifying text in the Security Considerations section about
how an ETR must not decapsulate and forward a packet that is not how an ETR must not decapsulate and forward a packet that is not
for its configured EID-prefix range. for its configured EID-prefix range.
B.2. Changes to draft-ietf-lisp-13.txt B.3. Changes to draft-ietf-lisp-13.txt
o Posted June 2011 to complete working group last call. o Posted June 2011 to complete working group last call.
o Tracker item 87. Put Yakov suggested wording in the EID-prefix o Tracker item 87. Put Yakov suggested wording in the EID-prefix
definition section to reference [INTERWORK] and [LISP-DEPLOY] definition section to reference [INTERWORK] and [LISP-DEPLOY]
about discussion on transition and access mechanisms. about discussion on transition and access mechanisms.
o Change "ITRs" to "ETRs" in the Locator Status Bit definition o Change "ITRs" to "ETRs" in the Locator Status Bit definition
section and data packet description section per Damien's comment. section and data packet description section per Damien's comment.
skipping to change at page 79, line 21 skipping to change at page 78, line 30
o Remove Security Area Statement title and reword section with o Remove Security Area Statement title and reword section with
Eliot's provided text. The text was agreed upon by LISP-WG chairs Eliot's provided text. The text was agreed upon by LISP-WG chairs
and Security ADs. and Security ADs.
o Remove word "potential" from the over-claiming paragraph of the o Remove word "potential" from the over-claiming paragraph of the
Security Considerations section per Stephen's request. Security Considerations section per Stephen's request.
o Wordsmithing and other editorial comments from Alia. o Wordsmithing and other editorial comments from Alia.
B.3. Changes to draft-ietf-lisp-12.txt B.4. Changes to draft-ietf-lisp-12.txt
o Posted April 2011. o Posted April 2011.
o Tracker item 87. Provided rewording how an EID-prefix can be o Tracker item 87. Provided rewording how an EID-prefix can be
resued in the definition section of "EID-prefix". resued in the definition section of "EID-prefix".
o Tracker item 95. Change "eliminate" to "defer" in section 4.1. o Tracker item 95. Change "eliminate" to "defer" in section 4.1.
o Tracker item 110. Added that the Mapping Protocol Data field in o Tracker item 110. Added that the Mapping Protocol Data field in
the Map-Reply message is only used when needed by the particular the Map-Reply message is only used when needed by the particular
skipping to change at page 80, line 34 skipping to change at page 79, line 45
indicating that site parittioning is under investigation. indicating that site parittioning is under investigation.
o Tracker item 58. Added last paragraph of Security Considerations o Tracker item 58. Added last paragraph of Security Considerations
section about how to protect inner header EID address spoofing section about how to protect inner header EID address spoofing
attacks. attacks.
o Add suggested Sam text to indicate that all security concerns need o Add suggested Sam text to indicate that all security concerns need
not be addressed for moving document to Experimental RFC status. not be addressed for moving document to Experimental RFC status.
Put this in a subsection of the Secuirty Considerations section. Put this in a subsection of the Secuirty Considerations section.
B.4. Changes to draft-ietf-lisp-11.txt B.5. Changes to draft-ietf-lisp-11.txt
o Posted March 30, 2011. o Posted March 30, 2011.
o Change IANA URL. The URL we had pointed to a general protocol o Change IANA URL. The URL we had pointed to a general protocol
numbers page. numbers page.
o Added the "s" bit to the Map-Request to allow SMR-invoked Map- o Added the "s" bit to the Map-Request to allow SMR-invoked Map-
Requests to be sent to a MN ETR via the map-server. Requests to be sent to a MN ETR via the map-server.
o Generalize text for the defintion of Reencapsuatling tunnels. o Generalize text for the defintion of Reencapsuatling tunnels.
skipping to change at page 81, line 26 skipping to change at page 80, line 38
reachability. reachability.
o Change "BGP RIB" to "RIB" per Clarence's comment. o Change "BGP RIB" to "RIB" per Clarence's comment.
o Fixed complaints by IDnits. o Fixed complaints by IDnits.
o Add subsection to Security Considerations section indicating how o Add subsection to Security Considerations section indicating how
EID-prefix overclaiming in Map-Replies is for further study and EID-prefix overclaiming in Map-Replies is for further study and
add a reference to LISP-SEC. add a reference to LISP-SEC.
B.5. Changes to draft-ietf-lisp-10.txt B.6. Changes to draft-ietf-lisp-10.txt
o Posted March 2011. o Posted March 2011.
o Add p-bit to Map-Request so there is documentary reasons to know o Add p-bit to Map-Request so there is documentary reasons to know
when a PITR has sent a Map-Request to an ETR. when a PITR has sent a Map-Request to an ETR.
o Add Map-Notify message which is used to acknowledge a Map-Register o Add Map-Notify message which is used to acknowledge a Map-Register
message sent to a Map-Server. message sent to a Map-Server.
o Add M-bit to the Map-Register message so an ETR that wants an o Add M-bit to the Map-Register message so an ETR that wants an
skipping to change at page 81, line 41 skipping to change at page 81, line 4
when a PITR has sent a Map-Request to an ETR. when a PITR has sent a Map-Request to an ETR.
o Add Map-Notify message which is used to acknowledge a Map-Register o Add Map-Notify message which is used to acknowledge a Map-Register
message sent to a Map-Server. message sent to a Map-Server.
o Add M-bit to the Map-Register message so an ETR that wants an o Add M-bit to the Map-Register message so an ETR that wants an
acknowledgment for the Map-Register can request one. acknowledgment for the Map-Register can request one.
o Add S-bit to the ECM and Map-Reply messages to describe security o Add S-bit to the ECM and Map-Reply messages to describe security
data that can be present in each message. Then refer to data that can be present in each message. Then refer to
[LISP-SEC] for expansive details. [LISP-SEC] for expansive details.
o Add Network Management Considerations section and point to the MIB o Add Network Management Considerations section and point to the MIB
and LIG drafts. and LIG drafts.
o Remove the word "simple" per Yakov's comments. o Remove the word "simple" per Yakov's comments.
B.6. Changes to draft-ietf-lisp-09.txt B.7. Changes to draft-ietf-lisp-09.txt
o Posted October 2010. o Posted October 2010.
o Add to IANA Consideration section about the use of LCAF Type o Add to IANA Consideration section about the use of LCAF Type
values that accepted and maintained by the IANA registry and not values that accepted and maintained by the IANA registry and not
the LCAF specification. the LCAF specification.
o Indicate that implementations should be able to receive LISP o Indicate that implementations should be able to receive LISP
control messages when either UDP port is 4342, so they can be control messages when either UDP port is 4342, so they can be
robust in the face of intervening NAT boxes. robust in the face of intervening NAT boxes.
o Add paragraph to SMR section to indicate that an ITR does not need 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 to respond to an SMR-based Map-Request when it has no map-cache
entry for the SMR source's EID-prefix. entry for the SMR source's EID-prefix.
B.7. Changes to draft-ietf-lisp-08.txt B.8. 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 84, line 5 skipping to change at page 83, line 17
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.8. Changes to draft-ietf-lisp-07.txt B.9. 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 85, line 27 skipping to change at page 84, line 38
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.9. Changes to draft-ietf-lisp-06.txt B.10. 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 86, line 37 skipping to change at page 85, line 47
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.10. Changes to draft-ietf-lisp-05.txt B.11. 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 87, line 16 skipping to change at page 86, line 27
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.11. Changes to draft-ietf-lisp-04.txt B.12. 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 89, line 10 skipping to change at page 88, line 18
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.12. Changes to draft-ietf-lisp-03.txt B.13. 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.13. Changes to draft-ietf-lisp-02.txt B.14. 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.14. Changes to draft-ietf-lisp-01.txt B.15. 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.15. Changes to draft-ietf-lisp-00.txt B.16. 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. 61 change blocks. 
124 lines changed or deleted 116 lines changed or added

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