draft-ietf-lisp-13.txt   draft-ietf-lisp-14.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 23, 2011 D. Lewis Expires: December 31, 2011 D. Lewis
cisco Systems cisco Systems
June 21, 2011 June 29, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-13 draft-ietf-lisp-14
Abstract Abstract
This draft describes a network-based protocol that enables separation This draft describes a network-based protocol that enables separation
of IP addresses into two new numbering spaces: Endpoint Identifiers of IP addresses into two new numbering spaces: Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). No changes are required to (EIDs) and Routing Locators (RLOCs). No changes are required to
either host protocol stacks or to the "core" of the Internet either host protocol stacks or to the "core" of the Internet
infrastructure. LISP can be incrementally deployed, without a "flag infrastructure. LISP can be incrementally deployed, without a "flag
day", and offers traffic engineering, multi-homing, and mobility day", and offers traffic engineering, multi-homing, and mobility
benefits even to early adopters, when there are relatively few LISP- benefits even to early adopters, when there are relatively few LISP-
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2011. 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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
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 . . . . . . . . . . . . . . . . . . . 77
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78
B.1. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 78 B.1. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 78
B.2. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 78 B.2. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 78
B.3. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 80 B.3. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 79
B.4. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 80 B.4. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 80
B.5. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81 B.5. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 81
B.6. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 81 B.6. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81
B.7. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 83 B.7. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 82
B.8. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 85 B.8. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 84
B.9. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 86 B.9. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 85
B.10. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 86 B.10. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 86
B.11. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 88 B.11. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 87
B.12. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 88 B.12. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 89
B.13. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89 B.13. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 89
B.14. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 89 B.14. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 B.15. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
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 7, line 49 skipping to change at page 7, line 49
lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
The source EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts. located. An EID can be used by a host to refer to other hosts.
EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be
assigned in a hierarchical manner, independent of the network assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site may have site-local addition, an EID block assigned to a site may have site-local
structure (subnetting) for routing within the site; this structure structure (subnetting) for routing within the site; this structure
is not visible to the global routing system. When used in is not visible to the global routing system. In theory, the bit
discussions with other Locator/ID separation proposals, a LISP EID string that represents an EID for one device can represent an RLOC
will be called a "LEID". Throughout this document, any references for a different device. As the architecture is realized, if a
to "EID" refers to an LEID. given bit string is both an RLOC and an EID, it must refer to the
same entity in both cases. When used in discussions with other
Locator/ID separation proposals, a LISP EID will be called a
"LEID". Throughout this document, any references to "EID" refers
to an LEID.
EID-prefix: An EID-prefix is a power-of-two block of EIDs which are EID-prefix: An EID-prefix is a power-of-two block of EIDs which are
allocated to a site by an address allocation authority. EID- allocated to a site by an address allocation authority. EID-
prefixes are associated with a set of RLOC addresses which make up prefixes are associated with a set of RLOC addresses which make up
a "database mapping". EID-prefix allocations can be broken up a "database mapping". EID-prefix allocations can be broken up
into smaller blocks when an RLOC set is to be associated with the into smaller blocks when an RLOC set is to be associated with the
smaller EID-prefix. A globally routed address block (whether PI smaller EID-prefix. A globally routed address block (whether PI
or PA) is not inherently an EID-prefix. A globally routed address or PA) is not inherently an EID-prefix. A globally routed address
block may be used by its assignee as an EID block. The converse block may be used by its assignee as an EID block. The converse
is not supported. That is, a site which receives an explicitly is not supported. That is, a site which receives an explicitly
skipping to change at page 10, line 48 skipping to change at page 10, line 48
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.
There are a set of well defined actions that are encoded in a There are a set of well defined actions that are encoded in a
Negative Map-Reply. Negative Map-Reply.
Data Probe: A data-probe is a LISP-encapsulated data packet where Data Probe: A data-probe is a LISP-encapsulated data packet where
the inner header destination address equals the outer header the inner header destination address equals the outer header
destination address used to trigger a Map-Reply by a decapsulating destination address used to trigger a Map-Reply by a decapsulating
ETR. In addition, the original packet is decapsulated and ETR. In addition, the original packet is decapsulated and
delivered to the destination host. A Data Probe is used in some delivered to the destination host if the destination EID is in the
of the mapping database designs to "probe" or request a Map-Reply EID-prefix range configured on the ETR. Otherwise, the packet is
from an ETR; in other cases, Map-Requests are used. See each discarded. A Data Probe is used in some of the mapping database
mapping database design for details. designs to "probe" or request a Map-Reply from an ETR; in other
cases, Map-Requests are used. See each mapping database design
for details.
Proxy ITR (PITR): A PITR is also known as a PTR is defined and Proxy ITR (PITR): A PITR is also known as a PTR is defined and
described in [INTERWORK], a PITR acts like an ITR but does so on described in [INTERWORK], a PITR acts like an ITR but does so on
behalf of non-LISP sites which send packets to destinations at behalf of non-LISP sites which send packets to destinations at
LISP sites. LISP sites.
Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a
PETR acts like an ETR but does so on behalf of LISP sites which PETR acts like an ETR but does so on behalf of LISP sites which
send packets to destinations at non-LISP sites. send packets to destinations at non-LISP sites.
skipping to change at page 17, line 5 skipping to change at page 16, line 17
Since additional tunnel headers are prepended, the packet becomes Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed from the ITR to
the ETR. It is recommended in IPv4 that packets do not get the ETR. It is recommended in IPv4 that packets do not get
fragmented as they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. Instead, the packet
is dropped and an ICMP Too Big message is returned to the source. is dropped and an ICMP Too Big message is returned to the source.
This specification recommends that implementations support for one of This specification recommends that implementations support for one of
the proposed fragmentation and reassembly schemes. These two the proposed fragmentation and reassembly schemes. These two
existing schemes are detailed in Section 5.4. existing schemes are detailed in Section 5.4.
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the other header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the other header is in IPv4 packet
format). The next sub-sections illustrate packet formats for the
homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
combinations SHOULD be supported.
5.1. LISP IPv4-in-IPv4 Header Format 5.1. LISP IPv4-in-IPv4 Header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum | OH | Time to Live | Protocol = 17 | Header Checksum |
skipping to change at page 34, line 14 skipping to change at page 34, line 14
(0) No-Action: The map-cache is kept alive and no packet (0) No-Action: The map-cache is kept alive and no packet
encapsulation occurs. encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Drop: A packet that matches this map-cache entry is dropped. (3) Drop: A packet that matches this map-cache entry is dropped.
An ICMP Unreachable message SHOULD be sent.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent by a UDP-based message is always
set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a
Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
Authoritative bit is set to 0. This indicates to requesting ITRs Authoritative bit is set to 0. This indicates to requesting ITRs
that the Map-Reply was not originated by a LISP node managed at that the Map-Reply was not originated by a LISP node managed at
the site that owns the EID-prefix. the site that owns the EID-prefix.
Map-Version Number: When this 12-bit value is non-zero the Map-Reply Map-Version Number: When this 12-bit value is non-zero the Map-Reply
sender is informing the ITR what the version number is for the sender is informing the ITR what the version number is for the
skipping to change at page 37, line 13 skipping to change at page 37, line 13
Note that not all overlapping EID-prefixes need to be returned, only Note that not all overlapping EID-prefixes need to be returned, only
the more specifics (note in the second example above 10.0.0.0/8 was the more specifics (note in the second example above 10.0.0.0/8 was
not returned for requesting EID 10.1.5.5) entries for the matching not returned for requesting EID 10.1.5.5) entries for the matching
EID-prefix of the requesting EID. When more than one EID-prefix is EID-prefix of the requesting EID. When more than one EID-prefix is
returned, all SHOULD use the same Time-to-Live value so they can all returned, all SHOULD use the same Time-to-Live value so they can all
time out at the same time. When a more specific EID-prefix is time out at the same time. When a more specific EID-prefix is
received later, its Time-to-Live value in the Map-Reply record can be received later, its Time-to-Live value in the Map-Reply record can be
stored even when other less specifics exist. When a less specific stored even when other less specifics exist. When a less specific
EID-prefix is received later, its map-cache expiration time SHOULD be EID-prefix is received later, its map-cache expiration time SHOULD be
set to the minimum expiration time of any more specific EID-prefix in set to the minimum expiration time of any more specific EID-prefix in
the map-cache. the map-cache. This is done so the integrity of the EID-prefix set
is wholly maintained so no more-specific entries are removed from the
map-cache while keeping less-specific entries.
Map-Replies SHOULD be sent for an EID-prefix no more often than once Map-Replies SHOULD be sent for an EID-prefix no more often than once
per second to the same requesting router. For scalability, it is per second to the same requesting router. For scalability, it is
expected that aggregation of EID addresses into EID-prefixes will expected that aggregation of EID addresses into EID-prefixes will
allow one Map-Reply to satisfy a mapping for the EID addresses in the allow one Map-Reply to satisfy a mapping for the EID addresses in the
prefix range thereby reducing the number of Map-Request messages. prefix range thereby reducing the number of Map-Request messages.
Map-Reply records can have an empty locator-set. A negative Map- Map-Reply records can have an empty locator-set. A negative Map-
Reply is a Map-Reply with an empty locator-set. Negative Map-Replies Reply is a Map-Reply with an empty locator-set. Negative Map-Replies
convey special actions by the sender to the ITR or PTR which have convey special actions by the sender to the ITR or PTR which have
skipping to change at page 68, line 37 skipping to change at page 68, line 37
traffic steering would be limited to the traffic that is sent by this traffic steering would be limited to the traffic that is sent by this
ITR's site, and no more severe than if the site initiated a bandwidth ITR's site, and no more severe than if the site initiated a bandwidth
DoS attack on (one of) the ETR's ingress links. The ITR's site would DoS attack on (one of) the ETR's ingress links. The ITR's site would
typically gain no benefit from not respecting the weights, and would typically gain no benefit from not respecting the weights, and would
likely to receive better service by abiding by them. likely to receive better service by abiding by them.
To deal with map-cache exhaustion attempts in an ITR/PTR, the To deal with map-cache exhaustion attempts in an ITR/PTR, the
implementation should consider putting a maximum cap on the number of implementation should consider putting a maximum cap on the number of
entries stored with a reserve list for special or frequently accessed entries stored with a reserve list for special or frequently accessed
sites. This should be a configuration policy control set by the sites. This should be a configuration policy control set by the
network administrator who manages ITRs and PTRs. network administrator who manages ITRs and PTRs. When overlapping
EID-prefixes occur across multiple map-cache entries, the integrity
of the set must be wholly maintained. So if a more-specific entry
cannot be added due to reaching the maximum cap, then none of the
less specifics should be stored in the map-cache.
Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, Given that the ITR/PTR 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. It should be noted that an undersized cache in an ITR/PTR not best. It should be noted that an undersized cache in an ITR/PTR not
only causes adverse affect on the site or region they support, but only causes adverse affect on the site or region they support, but
may also cause increased Map-Request load on the mapping system. may also cause increased Map-Request load on the mapping system.
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. ETRs MUST NOT decapsulate EID-prefix range prior to encapsulation. An ETR must only
and forward packets into their site where the inner header decapsulate and forward datagrams with an inner header destination
destination EID does not belong to the ETR's EID-prefix range for the that matches one of its EID-prefix ranges. If, upon receipt and
site. If a LISP encapsulated packet arrives at an ETR, it MAY decapsulation, the destination EID of a datagram does not match one
of the ETR's configured EID-prefixes, the ETR MUST drop the
datragram. If a LISP encapsulated packet arrives at an ETR, it MAY
compare the inner header source EID address and the outer header compare the inner header source EID address and the outer header
source RLOC address with the mapping that exists in the mapping source RLOC address with the mapping that exists in the mapping
database. Then when spoofing attacks occur, the outer header source database. Then when spoofing attacks occur, the outer header source
RLOC address can be used to trace back the attack to the source site, RLOC address can be used to trace back the attack to the source site,
using existing operational tools. using existing operational tools.
This experimental specification does not address automated key This experimental specification does not address automated key
management (AKM). BCP 107 provides guidance in this area. In management (AKM). BCP 107 provides guidance in this area. In
addition, at the time of this writing, substantial work is being addition, at the time of this writing, substantial work is being
undertaken to improve security of the routing system [KARP], [RPKI], undertaken to improve security of the routing system [KARP], [RPKI],
skipping to change at page 78, line 7 skipping to change at page 78, 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-13.txt B.1. Changes to draft-ietf-lisp-14.txt
o Post working group last call and pre-IESG last call review.
o Indicate that an ICMP Unreachable message should be sent when a
packet matches a drop-based negative map-cache entry.
o Indicate how a map-cache set of overlapping EID-prefixes must
maintian integrity when the map-cache maximum cap is reached.
o Add Joel's description for the definition of an EID, that the bit
string value can be an RLOC for another device in abstract but the
architecture allows it to be an EID of one device and the same
value as an RLOC for another device.
o In the "Tunnel Encapsulation Details" section, indicate that 4
combinations of encapsulation are supported.
o Add what ETR should do for a Data-Probe when received for a
destination EID outside of its EID-prefix range. This was added
in the Data Probe definition section.
o Added text indicating that more-specific EID-prefixes must not be
removed when less-specific entries stay in the map-cache. This is
to preserve the integrity of the EID-prefix set.
o Add clarifying text in the Security Considerations section about
how an ETR must not decapsulate and forward a packet that is not
for its configured EID-prefix range.
B.2. 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 78, line 40 skipping to change at page 79, line 21
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.2. Changes to draft-ietf-lisp-12.txt B.3. 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 5 skipping to change at page 80, line 34
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.3. Changes to draft-ietf-lisp-11.txt B.4. 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 80, line 45 skipping to change at page 81, line 26
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.4. Changes to draft-ietf-lisp-10.txt B.5. 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 20 skipping to change at page 81, line 48
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.5. Changes to draft-ietf-lisp-09.txt B.6. 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.6. Changes to draft-ietf-lisp-08.txt B.7. 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 83, line 26 skipping to change at page 84, line 5
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.7. Changes to draft-ietf-lisp-07.txt B.8. 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 5 skipping to change at page 85, line 27
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.8. Changes to draft-ietf-lisp-06.txt B.9. 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 13 skipping to change at page 86, line 37
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.9. Changes to draft-ietf-lisp-05.txt B.10. 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 86, line 41 skipping to change at page 87, line 16
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.10. Changes to draft-ietf-lisp-04.txt B.11. 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 88, line 32 skipping to change at page 89, line 10
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.11. Changes to draft-ietf-lisp-03.txt B.12. 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.12. Changes to draft-ietf-lisp-02.txt B.13. 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.13. Changes to draft-ietf-lisp-01.txt B.14. 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.14. Changes to draft-ietf-lisp-00.txt B.15. 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. 26 change blocks. 
47 lines changed or deleted 102 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/