draft-ietf-lisp-18.txt   draft-ietf-lisp-19.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: June 16, 2012 D. Lewis Expires: July 8, 2012 D. Lewis
cisco Systems cisco Systems
December 14, 2011 January 5, 2012
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-18 draft-ietf-lisp-19
Abstract Abstract
This draft describes a network layer based protocol that enables This draft describes a network layer based protocol that enables
separation of IP addresses into two new numbering spaces: Endpoint separation of IP addresses into two new numbering spaces: Endpoint
Identifiers (EIDs) and Routing Locators (RLOCs). No changes are Identifiers (EIDs) and Routing Locators (RLOCs). No changes are
required to either host protocol stacks or to the "core" of the required to either host protocol stacks or to the "core" of the
Internet infrastructure. LISP can be incrementally deployed, without Internet infrastructure. LISP can be incrementally deployed, without
a "flag day", and offers traffic engineering, multi-homing, and a "flag day", and offers traffic engineering, multi-homing, and
mobility benefits to early adopters, even when there are relatively mobility benefits to early adopters, even when there are relatively
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 16, 2012. This Internet-Draft will expire on July 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 72 14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 72
14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 72 14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 72
14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 72 14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 72
14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 73 14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 73
15. Known Open Issues and Areas of Future Work . . . . . . . . . . 74 15. Known Open Issues and Areas of Future Work . . . . . . . . . . 74
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76
16.1. Normative References . . . . . . . . . . . . . . . . . . . 76 16.1. Normative References . . . . . . . . . . . . . . . . . . . 76
16.2. Informative References . . . . . . . . . . . . . . . . . . 77 16.2. Informative References . . . . . . . . . . . . . . . . . . 77
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 81
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 82 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 82
B.1. Changes to draft-ietf-lisp-18.txt . . . . . . . . . . . . 82 B.1. Changes to draft-ietf-lisp-19.txt . . . . . . . . . . . . 82
B.2. Changes to draft-ietf-lisp-17.txt . . . . . . . . . . . . 82 B.2. Changes to draft-ietf-lisp-18.txt . . . . . . . . . . . . 82
B.3. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 82 B.3. Changes to draft-ietf-lisp-17.txt . . . . . . . . . . . . 82
B.4. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 82 B.4. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 82
B.5. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 82 B.5. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 82
B.6. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 83 B.6. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 82
B.7. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 84 B.7. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 83
B.8. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 85 B.8. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 84
B.9. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 86 B.9. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 85
B.10. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 86 B.10. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 86
B.11. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 87 B.11. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 86
B.12. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 88 B.12. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 87
B.13. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 90 B.13. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 88
B.14. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 91 B.14. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 90
B.15. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 92 B.15. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 91
B.16. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 93 B.16. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 92
B.17. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 94 B.17. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 93
B.18. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 94 B.18. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 94
B.19. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 94 B.19. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 94
B.20. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95
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
skipping to change at page 15, line 26 skipping to change at page 15, line 26
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 o Map-Requests can be sent on the underlying routing system
topology, to a mapping database system, or directly over an topology, to a mapping database system, or directly over an
alternative topology [ALT]. alternative topology [ALT]. A Map-Request is sent for an external
destination when the destination is not found in the forwarding
table or matches a default route.
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.example.com wants to communicate with server Client host1.abc.example.com wants to communicate with server
host2.xyz.example.com: host2.xyz.example.com:
1. host1.abc.example.com wants to open a TCP connection to 1. host1.abc.example.com wants to open a TCP connection to
host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally-assigned address of address is the destination EID. The locally-assigned address of
skipping to change at page 24, line 44 skipping to change at page 24, line 44
bytes, it resolves the MTU issue by first splitting the original bytes, it resolves the MTU issue by first splitting the original
packet into 2 equal-sized fragments. A LISP header is then prepended packet into 2 equal-sized fragments. A LISP header is then prepended
to each fragment. The size of the encapsulated fragments is then to each fragment. The size of the encapsulated fragments is then
(S/2 + H), which is less than the ITR's estimate of the path MTU (S/2 + H), which is less than the ITR's estimate of the path MTU
between the ITR and its correspondent ETR. between the ITR and its correspondent ETR.
When an ETR receives encapsulated fragments, it treats them as two When an ETR receives encapsulated fragments, it treats them as two
individually encapsulated packets. It strips the LISP headers then individually encapsulated packets. It strips the LISP headers then
forwards each fragment to the destination host of the destination forwards each fragment to the destination host of the destination
site. The two fragments are reassembled at the destination host into site. The two fragments are reassembled at the destination host into
the single IP datagram that was originated by the source host. the single IP datagram that was originated by the source host. Note
that reassembly can happen at the ETR if the encapsulated packet was
fragmented at or after the ITR.
This behavior is performed by the ITR when the source host originates This behavior is performed by the ITR when the source host originates
a packet with the DF field of the IP header is set to 0. When the DF a packet with the DF field of the IP header is set to 0. When the DF
field of the IP header is set to 1, or the packet is an IPv6 packet field of the IP header is set to 1, or the packet is an IPv6 packet
originated by the source host, the ITR will drop the packet when the originated by the source host, the ITR will drop the packet when the
size is greater than L, and sends an ICMP Too Big message to the size is greater than L, and sends an ICMP Too Big message to the
source with a value of S, where S is (L - H). source with a value of S, where S is (L - H).
When the outer header encapsulation uses an IPv4 header, an When the outer header encapsulation uses an IPv4 header, an
implementation SHOULD set the DF bit to 1 so ETR fragment reassembly implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
skipping to change at page 32, line 10 skipping to change at page 32, line 10
Mapping Protocol Data: This field is optional and present when the Mapping Protocol Data: This field is optional and present when the
UDP length indicates there is enough space in the packet to UDP length indicates there is enough space in the packet to
include it. include it.
6.1.3. EID-to-RLOC UDP Map-Request Message 6.1.3. EID-to-RLOC UDP Map-Request Message
A Map-Request is sent from an ITR when it needs a mapping for an EID, A Map-Request is sent from an ITR when it needs a mapping for an EID,
wants to test an RLOC for reachability, or wants to refresh a mapping wants to test an RLOC for reachability, or wants to refresh a mapping
before TTL expiration. For the initial case, the destination IP before TTL expiration. For the initial case, the destination IP
address used for the Map-Request is the destination-EID from the address used for the Map-Request is the data packet's destination
packet which had a mapping cache lookup failure. For the latter two address (i.e. the destination-EID) which had a mapping cache lookup
cases, the destination IP address used for the Map-Request is one of failure. For the latter two cases, the destination IP address used
the RLOC addresses from the locator-set of the map cache entry. The for the Map-Request is one of the RLOC addresses from the locator-set
source address is either an IPv4 or IPv6 RLOC address depending if of the map cache entry. The source address is either an IPv4 or IPv6
the Map-Request is using an IPv4 versus IPv6 header, respectively. RLOC address depending if the Map-Request is using an IPv4 versus
In all cases, the UDP source port number for the Map-Request message IPv6 header, respectively. In all cases, the UDP source port number
is an ITR/PITR selected 16-bit value and the UDP destination port for the Map-Request message is an ITR/PITR selected 16-bit value and
number is set to the well-known destination port number 4342. A the UDP destination port number is set to the well-known destination
successful Map-Reply, which is one that has a nonce that matches an port number 4342. A successful Map-Reply, which is one that has a
outstanding Map-Request nonce, will update the cached set of RLOCs nonce that matches an outstanding Map-Request nonce, will update the
associated with the EID prefix range. cached set of RLOCs associated with the EID prefix range.
One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
be filled in by the ITR. The number of fields (minus 1) encoded MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST
be placed in the IRC field. The ITR MAY include all locally be placed in the IRC field. The ITR MAY include all locally
configured locators in this list or just provide one locator address configured locators in this list or just provide one locator address
from each address family it supports. If the ITR erroneously from each address family it supports. If the ITR erroneously
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request. Request.
Map-Requests can also be LISP encapsulated using UDP destination port Map-Requests can also be LISP encapsulated using UDP destination port
skipping to change at page 32, line 45 skipping to change at page 32, line 45
on encapsulated Map-Requests and Map-Resolvers can be found in on encapsulated Map-Requests and Map-Resolvers can be found in
[LISP-MS]. [LISP-MS].
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-
Request for the same EID-prefix be sent no more than once per second. Request for the same EID-prefix be sent no more than once per second.
An ITR that is configured with mapping database information (i.e. it An ITR that is configured with mapping database information (i.e. it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the map-cache, it may originate a "verifying not have this mapping in the map-cache, it MAY originate a "verifying
Map-Request", addressed to the map-requesting ITR. If the ETR has a Map-Request", addressed to the map-requesting ITR and the ETR MAY add
map-cache entry that matches the "piggybacked" EID and the RLOC is in a map-cache entry. If the ETR has a map-cache entry that matches the
the locator-set for the entry, then it may send the "verifying Map- "piggybacked" EID and the RLOC is in the locator-set for the entry,
Request" directly to the originating Map-Request source. If the RLOC then it may send the "verifying Map-Request" directly to the
is not in the locator-set, then the ETR MUST send the "verifying Map- originating Map-Request source. If the RLOC is not in the locator-
Request" to the "piggybacked" EID. Doing this forces the "verifying set, then the ETR MUST send the "verifying Map-Request" to the
Map-Request" to go through the mapping database system to reach the "piggybacked" EID. Doing this forces the "verifying Map-Request" to
authoritative source of information about that EID, guarding against go through the mapping database system to reach the authoritative
RLOC-spoofing in in the "piggybacked" mapping data. source of information about that EID, guarding against RLOC-spoofing
in in the "piggybacked" mapping data.
6.1.4. Map-Reply Message Format 6.1.4. Map-Reply Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count | |Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 11 skipping to change at page 41, line 11
sending a Map-Register message. The Map-Notify message sent by a sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to an acknowledge receipt of a Map-Register Map-Server is used to an acknowledge receipt of a Map-Register
message. message.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages.
Since the Map-Register message is authenticated, the nonce field Since the Map-Register message is authenticated, the nonce field
is not needed for any security function. is not currently used for any security function but may be in the
future as part of an anti-replay solution.
Key ID: A configured ID to find the configured Message Key ID: A configured ID to find the configured Message
Authentication Code (MAC) algorithm and key value used for the Authentication Code (MAC) algorithm and key value used for the
authentication function. See Section 14.4 for codepoint authentication function. See Section 14.4 for codepoint
assignments. assignments.
Authentication Data Length: The length in bytes of the Authentication Data Length: The length in bytes of the
Authentication Data field that follows this field. The length of Authentication Data field that follows this field. The length of
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
skipping to change at page 70, line 15 skipping to change at page 70, line 15
Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings, Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings,
cache sizing and maintenance is an issue to be kept in mind during cache sizing and maintenance is an issue to be kept in mind during
implementation. It is a good idea to have instrumentation in place implementation. It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work will be used to determine which cache management strategies work
best. In general, it is difficult to defend against cache trashing best. In general, it is difficult to defend against cache trashing
attacks. It should be noted that an undersized cache in an ITR/PITR attacks. It should be noted that an undersized cache in an ITR/PITR
not only causes adverse affect on the site or region they support, not only causes adverse affect on the site or region they support,
but may also cause increased Map-Request load on the mapping system. but may also cause increased Map-Request load on the mapping system.
"Piggybacked" mapping data discussed in Section 6.1.3 specifies how
to handle such mappings and includes the possibility for an ETR to
temporarily accept such a mapping before verification when running in
"trusted" environments. In such cases, there is a potential threat
that a fake mapping could be inserted (even if only for a short
period) into a map-cache. As noted in Section 6.1.3, an ETR MUST be
specifically configured to run in such a mode and might usefully only
consider some specific ITRs as also running in that same trusted
environment.
There is a security risk implicit in the fact that ETRs generate the There is a security risk implicit in the fact that ETRs generate the
EID prefix to which they are responding. An ETR can claim a shorter EID prefix to which they are responding. An ETR can claim a shorter
prefix than it is actually responsible for. Various mechanisms to prefix than it is actually responsible for. Various mechanisms to
ameliorate or resolve this issue will be examined in the future, ameliorate or resolve this issue will be examined in the future,
[LISP-SEC]. [LISP-SEC].
Spoofing of inner header addresses of LISP encapsulated packets is Spoofing of inner header addresses of LISP encapsulated packets is
possible like with any tunneling mechanism. ITRs MUST verify the possible like with any tunneling mechanism. ITRs MUST verify the
source address of a packet to be an EID that belongs to the site's source address of a packet to be an EID that belongs to the site's
EID-prefix range prior to encapsulation. An ETR must only EID-prefix range prior to encapsulation. An ETR must only
skipping to change at page 82, line 7 skipping to change at page 82, line 7
LISP working group draft. LISP working group draft.
The LISP working group would like to give a special thanks to Jari The LISP working group would like to give a special thanks to Jari
Arkko, the Internet Area AD at the time the set of LISP documents Arkko, the Internet Area AD at the time the set of LISP documents
were being prepared for IESG last call, for his meticulous review and were being prepared for IESG last call, for his meticulous review and
detail commentary on the 7 working group last call drafts progressing detail commentary on the 7 working group last call drafts progressing
toward experimental RFCs. toward experimental RFCs.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-18.txt B.1. Changes to draft-ietf-lisp-19.txt
o Posted January 2012 for Stephen Farrell's comment resolution.
B.2. Changes to draft-ietf-lisp-18.txt
o Posted December 2011 after reflecting comments from IANA. o Posted December 2011 after reflecting comments from IANA.
o Create reference to sections 5.4.1 and 5.4.2 about DF bit setting o Create reference to sections 5.4.1 and 5.4.2 about DF bit setting
from section 5.3. from section 5.3.
o Inserted two references for Route-Returnability and on-path o Inserted two references for Route-Returnability and on-path
attacks in Security Considerations section. attacks in Security Considerations section.
B.2. Changes to draft-ietf-lisp-17.txt B.3. Changes to draft-ietf-lisp-17.txt
o Posted December 2011 after IETF last call comments. o Posted December 2011 after IETF last call comments.
o Make Map-Notify port assignment be 4342 in both source and o Make Map-Notify port assignment be 4342 in both source and
destination ports. This change was agreed on and put in [LISP-MS] destination ports. This change was agreed on and put in [LISP-MS]
but was not updated in this spec. but was not updated in this spec.
B.3. Changes to draft-ietf-lisp-16.txt B.4. Changes to draft-ietf-lisp-16.txt
o Posted October 2011 after AD review by Jari. o Posted October 2011 after AD review by Jari.
B.4. Changes to draft-ietf-lisp-15.txt B.5. Changes to draft-ietf-lisp-15.txt
o Posted July 2011. Fixing IDnits errors. o Posted July 2011. Fixing IDnits errors.
o Change description on how to select a source address for RLOC- 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" probe Map-Replies to refer to the "EID-to-RLOC Map-Reply Message"
section. section.
B.5. Changes to draft-ietf-lisp-14.txt B.6. 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
maintain integrity when the map-cache maximum cap is reached. maintain 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 83, line 20 skipping to change at page 83, line 22
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.6. Changes to draft-ietf-lisp-13.txt B.7. 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 84, line 5 skipping to change at page 84, line 7
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.7. Changes to draft-ietf-lisp-12.txt B.8. 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
reused in the definition section of "EID-prefix". reused 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 85, line 20 skipping to change at page 85, line 20
indicating that site partitioning is under investigation. indicating that site partitioning 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 Security Considerations section. Put this in a subsection of the Security Considerations section.
B.8. Changes to draft-ietf-lisp-11.txt B.9. 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 definition of Reencapsuatling tunnels. o Generalize text for the definition of Reencapsuatling tunnels.
skipping to change at page 86, line 13 skipping to change at page 86, line 13
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.9. Changes to draft-ietf-lisp-10.txt B.10. 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 86, line 35 skipping to change at page 86, line 35
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.10. Changes to draft-ietf-lisp-09.txt B.11. 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.11. Changes to draft-ietf-lisp-08.txt B.12. 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 88, line 42 skipping to change at page 88, line 42
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.12. Changes to draft-ietf-lisp-07.txt B.13. 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 90, line 17 skipping to change at page 90, line 17
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.13. Changes to draft-ietf-lisp-06.txt B.14. 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 91, line 26 skipping to change at page 91, line 26
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.14. Changes to draft-ietf-lisp-05.txt B.15. 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 92, line 5 skipping to change at page 92, line 5
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.15. Changes to draft-ietf-lisp-04.txt B.16. 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 93, line 44 skipping to change at page 93, line 44
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.16. Changes to draft-ietf-lisp-03.txt B.17. 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.17. Changes to draft-ietf-lisp-02.txt B.18. 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.18. Changes to draft-ietf-lisp-01.txt B.19. 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.19. Changes to draft-ietf-lisp-00.txt B.20. 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. 31 change blocks. 
69 lines changed or deleted 89 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/