draft-ietf-lisp-10.txt   draft-ietf-lisp-11.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: September 5, 2011 D. Lewis Expires: September 30, 2011 D. Lewis
cisco Systems cisco Systems
March 4, 2011 March 29, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-10 draft-ietf-lisp-11
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 September 5, 2011. This Internet-Draft will expire on September 30, 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 2, line 39 skipping to change at page 2, line 39
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24
5.5. Using Virtualization and Segmentation with LISP . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 30 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38
6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40
6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48
6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49
skipping to change at page 3, line 34 skipping to change at page 3, line 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67
13. Network Management Considerations . . . . . . . . . . . . . . 68 13. Network Management Considerations . . . . . . . . . . . . . . 68
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 69 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 69
14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 69 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 69
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
15.1. Normative References . . . . . . . . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . . 70
15.2. Informative References . . . . . . . . . . . . . . . . . . 71 15.2. Informative References . . . . . . . . . . . . . . . . . . 71
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 75 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 75
B.1. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 75 B.1. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 75
B.2. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 75 B.2. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 75
B.3. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 75 B.3. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 76
B.4. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 77 B.4. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 76
B.5. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 79 B.5. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 78
B.6. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 80 B.6. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 80
B.7. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 80 B.7. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 81
B.8. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 82 B.8. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 81
B.9. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 83 B.9. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 83
B.10. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 83 B.10. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 83
B.11. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 83 B.11. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 B.12. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85
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 9, line 35 skipping to change at page 9, line 35
mappings, it is dynamic, local to the ITR(s), and relatively small mappings, it is dynamic, local to the ITR(s), and relatively small
while the database is distributed, relatively static, and much while the database is distributed, relatively static, and much
more global in scope. more global in scope.
EID-to-RLOC Database: The EID-to-RLOC database is a global EID-to-RLOC Database: The EID-to-RLOC database is a global
distributed database that contains all known EID-prefix to RLOC distributed database that contains all known EID-prefix to RLOC
mappings. Each potential ETR typically contains a small piece of mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID prefixes the database: the EID-to-RLOC mappings for the EID prefixes
"behind" the router. These map to one of the router's own, "behind" the router. These map to one of the router's own,
globally-visible, IP addresses. The same database mapping entries globally-visible, IP addresses. The same database mapping entries
MUST be configured on all ETRs for a given site. That is, the MUST be configured on all ETRs for a given site. In a steady
EID-prefixes for the site and locator-set for each EID-prefix MUST state the EID-prefixes for the site and the locator-set for each
be the same on all ETRs so they consistently send Map-Reply EID-prefix MUST be the same on all ETRs. Procedures to enforce
messages with the same database mapping contents. and/or verify this are outside the scope of this document. Note
that there may be transient conditions when the EID-prefix for the
site and locator-set for each EID-prefix may not be the same on
all ETRs. This has no negative implications.
Recursive Tunneling: Recursive tunneling occurs when a packet has Recursive Tunneling: Recursive tunneling occurs when a packet has
more than one LISP IP header. Additional layers of tunneling may more than one LISP IP header. Additional layers of tunneling may
be employed to implement traffic engineering or other re-routing be employed to implement traffic engineering or other re-routing
as needed. When this is done, an additional "outer" LISP header as needed. When this is done, an additional "outer" LISP header
is added and the original RLOCs are preserved in the "inner" is added and the original RLOCs are preserved in the "inner"
header. Any references to tunnels in this specification refers to header. Any references to tunnels in this specification refers to
dynamic encapsulating tunnels and never are they statically dynamic encapsulating tunnels and never are they statically
configured. configured.
Reencapsulating Tunnels: Reencapsulating tunneling occurs when a Reencapsulating Tunnels: Reencapsulating tunneling occurs when an
packet has no more than one LISP IP header (two IP headers total) ETR removes a LISP header, then acts as an ITR to prepend another
and when it needs to be diverted to new RLOC, an ETR can LISP header. Doing this allows a packet to be re-routed by the
decapsulate the packet (remove the LISP header) and prepends a new re-encapsulating router without adding the overhead of additional
tunnel header, with new RLOC, on to the packet. Doing this allows tunnel headers. Any references to tunnels in this specification
a packet to be re-routed by the re-encapsulating router without refers to dynamic encapsulating tunnels and never are they
adding the overhead of additional tunnel headers. Any references statically configured.
to tunnels in this specification refers to dynamic encapsulating
tunnels and never are they statically configured.
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] and [RFC1700] for details. An IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An
AFI value of 0 used in this specification indicates an unspecified AFI value of 0 used in this specification indicates an unspecified
skipping to change at page 12, line 5 skipping to change at page 11, line 28
sending Map-Request messages. sending Map-Request messages.
Server-side: a term used in this document to indicate a connection Server-side: a term used in this document to indicate a connection
initiation attempt is being accepted for a destination EID. The initiation attempt is being accepted for a destination EID. The
ETR(s) at the destination LISP site are the first to send Map- ETR(s) at the destination LISP site are the first to send Map-
Replies to the source site initiating the connection. The ETR(s) Replies to the source site initiating the connection. The ETR(s)
at this destination site can obtain mappings by gleaning at this destination site can obtain mappings by gleaning
information from Map-Requests, Data-Probes, or encapsulated information from Map-Requests, Data-Probes, or encapsulated
packets. packets.
Locator-Status-Bits (LSBs): Locator status bits are present in the
LISP header. They are used by ITRs to inform ETRs about the up/
down status of all ITRs at the local site. These bits are used as
a hint to convey up/down router status and not path reachability
status. The LSBs can be verified by use of one of the Locator
Reachability Algoriths described in Section 6.3.
4. Basic Overview 4. Basic Overview
One key concept of LISP is that end-systems (hosts) operate the same One key concept of LISP is that end-systems (hosts) operate the same
way they do today. The IP addresses that hosts use for tracking way they do today. The IP addresses that hosts use for tracking
sockets, connections, and for sending and receiving packets do not sockets, connections, and for sending and receiving packets do not
change. In LISP terminology, these IP addresses are called Endpoint change. In LISP terminology, these IP addresses are called Endpoint
Identifiers (EIDs). Identifiers (EIDs).
Routers continue to forward packets based on IP destination Routers continue to forward packets based on IP destination
addresses. When a packet is LISP encapsulated, these addresses are addresses. When a packet is LISP encapsulated, these addresses are
skipping to change at page 28, line 22 skipping to change at page 28, line 22
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
6.1.2. Map-Request Message Format 6.1.2. Map-Request 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=1 |A|M|P|S|p| Reserved | IRC | Record Count | |Type=1 |A|M|P|S|p|s| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
skipping to change at page 29, line 24 skipping to change at page 29, line 24
treated as a locator reachability probe. The receiver SHOULD treated as a locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating the respond with a Map-Reply with the probe-bit set, indicating the
Map-Reply is a locator reachability probe reply, with the nonce Map-Reply is a locator reachability probe reply, with the nonce
copied from the Map-Request. See Section 6.3.2 for more details. copied from the Map-Request. See Section 6.3.2 for more details.
S: This is the SMR bit. See Section 6.6.2 for details. S: This is the SMR bit. See Section 6.6.2 for details.
p: This is the PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a PITR sends a
Map-Request. Map-Request.
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map-
Request.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
IRC: This 5-bit field is the ITR-RLOC Count which encodes the IRC: This 5-bit field is the ITR-RLOC Count which encodes the
additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-
Address) pair must always be encoded. Multiple ITR-RLOC Address Address) pair must always be encoded. Multiple ITR-RLOC Address
fields are used so a Map-Replier can select which destination fields are used so a Map-Replier can select which destination
address to use for a Map-Reply. The IRC value ranges from 0 to address to use for a Map-Reply. The IRC value ranges from 0 to
31, and for a value of 1, there are 2 ITR-RLOC addresses encoded 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.
skipping to change at page 37, line 41 skipping to change at page 37, line 41
message. The locator-set MUST be sorted in order of ascending IP message. The locator-set MUST be sorted in order of ascending IP
address where an IPv4 locator address is considered numerically 'less address where an IPv4 locator address is considered numerically 'less
than' an IPv6 locator address. than' an IPv6 locator address.
When sending a Map-Reply message, the destination address is copied When sending a Map-Reply message, the destination address is copied
from the one of the ITR-RLOC fields from the Map-Request. The ETR from the one of the ITR-RLOC fields from the Map-Request. The ETR
can choose a locator address from one of the address families it can choose a locator address from one of the address families it
supports. For Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address of the Map-Reply
is copied from the source address of the Data-Probe message which is is copied from the source address of the Data-Probe message which is
invoking the reply. The source address of the Map-Reply is one of invoking the reply. The source address of the Map-Reply is one of
the local locator addresses listed in the locator-set of any mapping the local IP addresses chosen to allow uRPF checks to succeed in the
record in the message and SHOULD be chosen to allow uRPF checks to upstream service provider. The destination port of a Map-Reply
succeed in the upstream service provider. The destination port of a message is copied from the source port of the Map-Request or Data-
Map-Reply message is copied from the source port of the Map-Request Probe and the source port of the Map-Reply message is set to the
or Data-Probe and the source port of the Map-Reply message is set to well-known UDP port 4342.
the well-known UDP port 4342.
6.1.5.1. Traffic Redirection with Coarse EID-Prefixes 6.1.5.1. Traffic Redirection with Coarse EID-Prefixes
When an ETR is misconfigured or compromised, it could return coarse When an ETR is misconfigured or compromised, it could return coarse
EID-prefixes in Map-Reply messages it sends. The EID-prefix could EID-prefixes in Map-Reply messages it sends. The EID-prefix could
cover EID-prefixes which are allocated to other sites redirecting cover EID-prefixes which are allocated to other sites redirecting
their traffic to the locators of the compromised site. their traffic to the locators of the compromised site.
To solve this problem, there are two basic solutions that could be To solve this problem, there are two basic solutions that could be
used. The first is to have Map-Servers proxy-map-reply on behalf of used. The first is to have Map-Servers proxy-map-reply on behalf of
skipping to change at page 46, line 42 skipping to change at page 46, line 42
When ITRs receive ICMP Network or Host Unreachable messages as a When ITRs receive ICMP Network or Host Unreachable messages as a
method to determine unreachability, they will refrain from using method to determine unreachability, they will refrain from using
Locators which are described in Locator lists of Map-Replies. Locators which are described in Locator lists of Map-Replies.
However, using this approach is unreliable because many network However, using this approach is unreliable because many network
operators turn off generation of ICMP Unreachable messages. operators turn off generation of ICMP Unreachable messages.
If an ITR does receive an ICMP Network or Host Unreachable message, If an ITR does receive an ICMP Network or Host Unreachable message,
it MAY originate its own ICMP Unreachable message destined for the it MAY originate its own ICMP Unreachable message destined for the
host that originated the data packet the ITR encapsulated. host that originated the data packet the ITR encapsulated.
Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
a locator address from a locator-set in a mapping entry matches a locator address from a locator-set in a mapping entry matches a
prefix. If it does not find one and BGP is running in the Default prefix. If it does not find one and BGP is running in the Default
Free Zone (DFZ), it can decide to not use the locator even though the Free Zone (DFZ), it can decide to not use the locator even though the
Loc-Status-Bits indicate the locator is up. In this case, the path Loc-Status-Bits indicate the locator is up. In this case, the path
from the ITR to the ETR that is assigned the locator is not from the ITR to the ETR that is assigned the locator is not
available. More details are in [LOC-ID-ARCH]. available. More details are in [LOC-ID-ARCH].
Optionally, an ITR can send a Map-Request to a Locator and if a Map- Optionally, an ITR can send a Map-Request to a Locator and if a Map-
Reply is returned, reachability of the Locator has been determined. Reply is returned, reachability of the Locator has been determined.
Obviously, sending such probes increases the number of control Obviously, sending such probes increases the number of control
messages originated by tunnel routers for active flows, so Locators messages originated by tunnel routers for active flows, so Locators
skipping to change at page 51, line 11 skipping to change at page 51, line 11
easy to update mappings. We assume new mappings will maintain the easy to update mappings. We assume new mappings will maintain the
same locator ordering as the old mapping but just have new locators same locator ordering as the old mapping but just have new locators
appended to the end of the list. So some ITRs can have a new mapping appended to the end of the list. So some ITRs can have a new mapping
while other ITRs have only an old mapping that is used until they while other ITRs have only an old mapping that is used until they
time out. When an ITR has only an old mapping but detects bits set time out. When an ITR has only an old mapping but detects bits set
in the loc-status-bits that correspond to locators beyond the list it in the loc-status-bits that correspond to locators beyond the list it
has cached, it simply ignores them. However, this can only happen has cached, it simply ignores them. However, this can only happen
for locator addresses that are lexicographically greater than the for locator addresses that are lexicographically greater than the
locator addresses in the existing locator-set. locator addresses in the existing locator-set.
When a locator record is inserted in the middle of a locator-set, to
maintain lexiographic order, the SMR procedure in Section 6.6.2 is
used to inform ITRs and PTRs of the new locator-status-bit mappings.
When a locator record is removed from a locator-set, ITRs that have When a locator record is removed from a locator-set, ITRs that have
the mapping cached will not use the removed locator because the xTRs the mapping cached will not use the removed locator because the xTRs
will set the loc-status-bit to 0. So even if the locator is in the will set the loc-status-bit to 0. So even if the locator is in the
list, it will not be used. For new mapping requests, the xTRs can list, it will not be used. For new mapping requests, the xTRs can
set the locator AFI to 0 (indicating an unspecified address), as well set the locator AFI to 0 (indicating an unspecified address), as well
as setting the corresponding loc-status-bit to 0. This forces ITRs as setting the corresponding loc-status-bit to 0. This forces ITRs
with old or new mappings to avoid using the removed locator. with old or new mappings to avoid using the removed locator.
If many changes occur to a mapping over a long period of time, one If many changes occur to a mapping over a long period of time, one
will find empty record slots in the middle of the locator-set and new will find empty record slots in the middle of the locator-set and new
skipping to change at page 55, line 19 skipping to change at page 55, line 19
LISP: LISP:
o When a tunnel encapsulated packet is received by an ETR, the outer o When a tunnel encapsulated packet is received by an ETR, the outer
destination address may not be the address of the router. This destination address may not be the address of the router. This
makes it challenging for the control plane to get packets from the makes it challenging for the control plane to get packets from the
hardware. This may be mitigated by creating special FIB entries hardware. This may be mitigated by creating special FIB entries
for the EID-prefixes of EIDs served by the ETR (those for which for the EID-prefixes of EIDs served by the ETR (those for which
the router provides an RLOC translation). These FIB entries are the router provides an RLOC translation). These FIB entries are
marked with a flag indicating that control plane processing should marked with a flag indicating that control plane processing should
be performed. The forwarding logic of testing for particular IP be performed. The forwarding logic of testing for particular IP
protocol number value is not necessary. No changes to existing, protocol number value is not necessary. There are a few proven
deployed hardware should be needed to support this. cases where no changes to existing deployed hardware were needed
to support the LISP data-plane.
o On an ITR, prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of adding more
bytes to a MAC rewrite string and prepending the string as part of bytes to a MAC rewrite string and prepending the string as part of
the outgoing encapsulation procedure. Routers that support GRE the outgoing encapsulation procedure. Routers that support GRE
tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
support this action. support this action.
o A packet's source address or interface the packet was received on o A packet's source address or interface the packet was received on
can be used to select a VRF (Virtual Routing/Forwarding). The can be used to select a VRF (Virtual Routing/Forwarding). The
VRF's routing table can be used to find EID-to-RLOC mappings. VRF's routing table can be used to find EID-to-RLOC mappings.
8. Deployment Scenarios 8. Deployment Scenarios
This section will explore how and where ITRs and ETRs can be deployed This section will explore how and where ITRs and ETRs can be deployed
and will discuss the pros and cons of each deployment scenario. and will discuss the pros and cons of each deployment scenario. For
a more detailed deployment recommendation, refer to [LISP-DEPLOY].
There are two basic deployment trade-offs to consider: centralized There are two basic deployment trade-offs to consider: centralized
versus distributed caches and flat, recursive, or re-encapsulating versus distributed caches and flat, recursive, or re-encapsulating
tunneling. tunneling. When deciding on centralized versus distributed caching,
the following issues should be considered:
When deciding on centralized versus distributed caching, the
following issues should be considered:
o Are the tunnel routers spread out so that the caches are spread o Are the tunnel routers spread out so that the caches are spread
across all the memories of each router? across all the memories of each router?
o Should management "touch points" be minimized by choosing few o Should management "touch points" be minimized by choosing few
tunnel routers, just enough for redundancy? tunnel routers, just enough for redundancy?
o In general, using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase management load,
since caches are built and stored dynamically. On the other hand, since caches are built and stored dynamically. On the other hand,
more ETRs does require more management since EID-prefix-to-RLOC more ETRs does require more management since EID-prefix-to-RLOC
skipping to change at page 68, line 5 skipping to change at page 67, line 31
DoS attack prevention will depend on implementations rate-limiting DoS attack prevention will depend on implementations rate-limiting
Map-Requests and Map-Replies to the control plane as well as rate- Map-Requests and Map-Replies to the control plane as well as rate-
limiting the number of data-triggered Map-Replies. limiting the number of data-triggered Map-Replies.
To deal with map-cache exhaustion attempts in an ITR/PTR, the To deal with map-cache exhaustion attempts in an ITR/PTR, the
implementation should consider putting a maximum cap on the number of implementation should consider putting a maximum cap on the number of
entries stored with a reserve list for special or frequently accessed entries stored with a reserve list for special or frequently accessed
sites. This should be a configuration policy control set by the sites. This should be a configuration policy control set by the
network administrator who manages ITRs and PTRs. network administrator who manages ITRs and PTRs.
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
implementation. It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work
best.
There is a potential security risk implicit in the fact that ETRs
generate the EID prefix to which they are responding. In theory, an
ETR can claim a shorter prefix than it is actually responsible for.
Various mechanisms to ameliorate or resolve this issue will be
examined in the future, [LISP-SEC].
13. Network Management Considerations 13. Network Management Considerations
Considerations for Network Management tools exist so the LISP Considerations for Network Management tools exist so the LISP
protocol suite can be operationally managed. The mechanisms can be protocol suite can be operationally managed. The mechanisms can be
found in [LISP-MIB] and [LISP-LIG]. found in [LISP-MIB] and [LISP-LIG].
14. IANA Considerations 14. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the LISP Authority (IANA) regarding registration of values related to the LISP
skipping to change at page 71, line 30 skipping to change at page 71, line 30
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[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-00.txt (work in Packets"", draft-eubanks-chimento-6man-00.txt (work in
progress), February 2009. progress), February 2009.
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 http://www.iana.org/numbers.html, Febuary 2007. NUMBERS http://www.iana.org/.../address-family-numbers,
Febuary 2007.
[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-06.txt (work in progress), March 2011. draft-ietf-lisp-alt-06.txt (work in progress), March 2011.
[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. 1999.
skipping to change at page 72, line 15 skipping to change at page 72, line 16
draft-ietf-lisp-interworking-02.txt (work in progress), draft-ietf-lisp-interworking-02.txt (work in progress),
March 2011. March 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-04.txt (work in
progress), October 2010. progress), October 2010.
[LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
"Renumbering: Threat or Menace?", Usenix , September 1996. "Renumbering: Threat or Menace?", Usenix , September 1996.
[LISP-DEPLOY]
Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis,
"LISP Network Element Deployment Considerations",
draft-jakab-lisp-deployment-02.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-01.txt (work in progress),
October 2010. 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. March 2009.
skipping to change at page 74, line 33 skipping to change at page 74, line 33
Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry
Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van
Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David
Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin,
Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu,
Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, and Chris Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White,
White. and Clarence Filsfils.
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-10.txt B.1. Changes to draft-ietf-lisp-11.txt
o Posted April 2011.
o Change IANA URL. The URL we had pointed to a general protocol
numbers page.
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.
o Generalize text for the defintion of Reencapsuatling tunnels.
o Add pargraph suggested by Joel to explain how implementation
experimentation will be used to determine the proper cache
management techniques.
o Add Yakov provided text for the definition of "EID-to-RLOC
"Database".
o Add reference in Section 8, Deployment Scenarios, to the
draft-jakab-lisp-deploy-02.txt draft.
o Clarify sentence about no hardware changes needed to support LISP
encapsulation.
o Add paragraph about what is the procedure when a locator is
inserted in the middle of a locator-set.
o Add a definition for Locator-Status-Bits so we can emphasize they
are used as a hint for router up/down status and not path
reachability.
o Change "BGP RIB" to "RIB" per Clarence's comment.
o Fixed complaints by IDnits.
o Add paragraph to Security Considerations section indicating how
EID-prefix overclaiming in Map-Replies is for further study and
add a reference to LISP-SEC.
B.2. 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 75, line 29 skipping to change at page 76, line 20
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.2. Changes to draft-ietf-lisp-09.txt B.3. 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.3. Changes to draft-ietf-lisp-08.txt B.4. 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 77, line 33 skipping to change at page 78, line 26
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.4. Changes to draft-ietf-lisp-07.txt B.5. 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 79, line 8 skipping to change at page 80, line 5
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.5. Changes to draft-ietf-lisp-06.txt B.6. 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 80, line 16 skipping to change at page 81, line 13
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.6. Changes to draft-ietf-lisp-05.txt B.7. 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 80, line 44 skipping to change at page 81, line 41
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.7. Changes to draft-ietf-lisp-04.txt B.8. 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 82, line 35 skipping to change at page 83, line 32
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.8. Changes to draft-ietf-lisp-03.txt B.9. 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.9. Changes to draft-ietf-lisp-02.txt B.10. 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.10. Changes to draft-ietf-lisp-01.txt B.11. 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.11. Changes to draft-ietf-lisp-00.txt B.12. 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. 32 change blocks. 
60 lines changed or deleted 137 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/