draft-ietf-lisp-05.txt   draft-ietf-lisp-06.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: April 2, 2010 D. Lewis Expires: July 30, 2010 D. Lewis
cisco Systems cisco Systems
September 29, 2009 January 25, 2010
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-05.txt draft-ietf-lisp-06.txt
Abstract
This draft describes a simple, incremental, network-based protocol to
implement separation of Internet addresses into Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). This mechanism requires no
changes to host stacks and no major changes to existing database
infrastructures. The proposed protocol can be implemented in a
relatively small number of routers.
This proposal was stimulated by the problem statement effort at the
Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
place in October 2006.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 47
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 April 2, 2010. This Internet-Draft will expire on July 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This draft describes a simple, incremental, network-based protocol to described in the BSD License.
implement separation of Internet addresses into Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). This mechanism requires no
changes to host stacks and no major changes to existing database
infrastructures. The proposed protocol can be implemented in a
relatively small number of routers.
This proposal was stimulated by the problem statement effort at the
Amsterdam IAB Routing and Addressing Workshop (RAWS), which took
place in October 2006.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17
skipping to change at page 2, line 39 skipping to change at page 2, line 38
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 30 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 30
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 34 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 35
6.1.7. Encapsualted Control Message Format . . . . . . . . . 36 6.1.7. Encapsualted Control Message Format . . . . . . . . . 37
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 38 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 39
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 39 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 40
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 42 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 43
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 43 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 44
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 44 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 45
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 45 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 46
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 45 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 46
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 46 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 47
7. Router Performance Considerations . . . . . . . . . . . . . . 48 7. Router Performance Considerations . . . . . . . . . . . . . . 49
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 49 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 50
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 50 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 51
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 50 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 51
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 51 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 52
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 52 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 53
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 53 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 54
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 53 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 54
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 53 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 54
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 55 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 56
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 55 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 56
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 55 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 56
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 55 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 56
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 57 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 58
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 57 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 58
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 59 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 60
12. Security Considerations . . . . . . . . . . . . . . . . . . . 60 12. Security Considerations . . . . . . . . . . . . . . . . . . . 61
13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 61 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 62
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1. Normative References . . . . . . . . . . . . . . . . . . . 64 14.1. Normative References . . . . . . . . . . . . . . . . . . . 65
14.2. Informative References . . . . . . . . . . . . . . . . . . 65 14.2. Informative References . . . . . . . . . . . . . . . . . . 66
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 69
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 69 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 70
B.1. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 69 B.1. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 70
B.2. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 69 B.2. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 71
B.3. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 71 B.3. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 71
B.4. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 71 B.4. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 73
B.5. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 72 B.5. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 74
B.6. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 72 B.6. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 B.7. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
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
Many years of discussion about the current IP routing and addressing Many years of discussion about the current IP routing and addressing
skipping to change at page 11, line 6 skipping to change at page 11, line 6
header (two IP headers total) and when it needs to be diverted to header (two IP headers total) and when it needs to be diverted to
new RLOC, an ETR can decapsulate the packet (remove the LISP new RLOC, an ETR can decapsulate the packet (remove the LISP
header) and prepends a new tunnel header, with new RLOC, on to the header) and prepends a new tunnel header, with new RLOC, on to the
packet. Doing this allows a packet to be re-routed by the re- packet. Doing this allows a packet to be re-routed by the re-
encapsulating router without adding the overhead of additional encapsulating router without adding the overhead of additional
tunnel headers. Any references to tunnels in this specification tunnel headers. Any references to tunnels in this specification
refers to dynamic encapsulating tunnels and never are they refers to dynamic encapsulating tunnels and never are they
statically configured. 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 header, an ITR IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
prepends or an ETR strips. header that follows the UDP header, an ITR prepends or an ETR
strips.
Address Family Indicator (AFI): a term used to describe an address Address Family Indicator (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] for details. IPv4 or IPv6 address. See [AFI] for details. An AFI value of 0
used in this specification indicates an unspecified encoded
address where the the length of the address is 0 bytes following
the 16-bit AFI value of 0.
Negative Mapping Entry: also known as a negative cache entry, is an Negative Mapping Entry: also known as a negative cache entry, is an
EID-to-RLOC entry where an EID-prefix is advertised or stored with EID-to-RLOC entry where an EID-prefix is advertised or stored with
no RLOCs. That is, the locator-set for the EID-to-RLOC entry is no RLOCs. That is, the locator-set for the EID-to-RLOC entry is
empty or has an encoded locator count of 0. This type of entry empty or has an encoded locator count of 0. This type of entry
could be used to describe a prefix from a non-LISP site, which is could be used to describe a prefix from a non-LISP site, which is
explicitly not in the mapping database. There are a set of well explicitly not in the mapping database. There are a set of well
defined actions that are encoded in a Negative Map-Reply. defined actions that are encoded in a Negative Map-Reply.
Data Probe: a LISP-encapsulated data packet where the inner header Data Probe: a LISP-encapsulated data packet where the inner header
destination address equals the outer header destination address destination address equals the outer header destination address
used to trigger a Map-Reply by a decapsulating ETR. In addition, used to trigger a Map-Reply by a decapsulating ETR. In addition,
the original packet is decapsulated and delivered to the the original packet is decapsulated and delivered to the
destination host. A Data Probe is used in some of the mapping destination host. A Data Probe is used in some of the mapping
database designs to "probe" or request a Map-Reply from an ETR; in database designs to "probe" or request a Map-Reply from an ETR; in
other cases, Map-Requests are used. See each mapping database other cases, Map-Requests are used. See each mapping database
design for details. design for details.
Proxy ITR (PITR): also known as a PTR is defined and described in
[INTERWORK], a PITR acts like an ITR but does so on behalf of non-
LISP sites which send packets to destinations at LISP sites.
Proxy ETR (PETR): is defined and described in [INTERWORK], a PETR
acts like an ETR but does so on behalf of LISP sites which send
packets to destinations at non-LISP sites.
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 13, line 28 skipping to change at page 13, line 28
o EIDs may also be structured (subnetted) in a manner suitable for o EIDs may also be structured (subnetted) in a manner suitable for
local routing within an autonomous system. local routing within an autonomous system.
An additional LISP header may be prepended to packets by a transit An additional LISP header may be prepended to packets by a transit
router (i.e. TE-ITR) when re-routing of the path for a packet is router (i.e. TE-ITR) when re-routing of the path for a packet is
desired. An obvious instance of this would be an ISP router that desired. An obvious instance of this would be an ISP router that
needs to perform traffic engineering for packets in flow through its needs to perform traffic engineering for packets in flow through its
network. In such a situation, termed Recursive Tunneling, an ISP network. In such a situation, termed Recursive Tunneling, an ISP
transit acts as an additional ingress tunnel router and the RLOC it transit acts as an additional ingress tunnel router and the RLOC it
uses for the new prepended header would be either an TE-ETR within uses for the new prepended header would be either a TE-ETR within the
the ISP (along intra-ISP traffic engineered path) or in an TE-ETR ISP (along intra-ISP traffic engineered path) or a TE-ETR within
within another ISP (an inter-ISP traffic engineered path, where an another ISP (an inter-ISP traffic engineered path, where an agreement
agreement to build such a path exists). to build such a path exists).
This specification mandates that no more than two LISP headers get This specification mandates that no more than two LISP headers get
prepended to a packet. This avoids excessive packet overhead as well prepended to a packet. This avoids excessive packet overhead as well
as possible encapsulation loops. It is believed two headers is as possible encapsulation loops. It is believed two headers is
sufficient, where the first prepended header is used at a site for sufficient, where the first prepended header is used at a site for
Location/Identity separation and second prepended header is used Location/Identity separation and second prepended header is used
inside a service provider for Traffic Engineering purposes. inside a service provider for Traffic Engineering purposes.
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
For example, the ITR for a particular end-to-end packet exchange For example, the ITR for a particular end-to-end packet exchange
skipping to change at page 20, line 19 skipping to change at page 20, line 19
L: this is the Locator-Status-Bits field enabled bit. When this bit L: this is the Locator-Status-Bits field enabled bit. When this bit
is set to 1, the Locator-Status-Bits in the second 32-bits of the is set to 1, the Locator-Status-Bits in the second 32-bits of the
LISP header are in use. LISP header are in use.
E: this is the echo-nonce-request bit. When this bit is set to 1, E: this is the echo-nonce-request bit. When this bit is set to 1,
the N bit must be 1. This bit should be ignored and has no the N bit must be 1. This bit should be ignored and has no
meaning when the N bit is set to 0. See section Section 6.3.1 for meaning when the N bit is set to 0. See section Section 6.3.1 for
details. details.
rflags: this 4-bit field is reserved for future flag use. It is set rflags: this 5-bit field is reserved for future flag use. It is set
to 0 on transmit and ignored on receipt. to 0 on transmit and ignored on receipt.
LISP Nonce: is a 24-bit value that is randomly generated by an ITR LISP Nonce: is a 24-bit value that is randomly generated by an ITR
when the N-bit is set to 1. The nonce is also used when the E-bit when the N-bit is set to 1. The nonce is also used when the E-bit
is set to request the nonce value to be echoed by the other side is set to request the nonce value to be echoed by the other side
when packets are returned. When the E-bit is clear but the N-bit when packets are returned. When the E-bit is clear but the N-bit
is set, an ITR is either echoing a previously requested echo-nonce is set, a remote ITR is either echoing a previously requested
or providing a random nonce. See section Section 6.3.1 for more echo-nonce or providing a random nonce. See section Section 6.3.1
details. for more details.
LISP Locator Status Bits: in the LISP header are set by an ITR to LISP Locator Status Bits: in the LISP header are set by an ITR to
indicate to an ETR the up/down status of the Locators in the indicate to an ETR the up/down status of the Locators in the
source site. Each RLOC in a Map-Reply is assigned an ordinal source site. Each RLOC in a Map-Reply is assigned an ordinal
value from 0 to n-1 (when there are n RLOCs in a mapping entry). value from 0 to n-1 (when there are n RLOCs in a mapping entry).
The Locator Status Bits are numbered from 0 to n-1 from the least The Locator Status Bits are numbered from 0 to n-1 from the least
significant bit of the 32-bit field. When a bit is set to 1, the significant bit of the 32-bit field. When a bit is set to 1, the
ITR is indicating to the ETR the RLOC associated with the bit ITR is indicating to the ETR the RLOC associated with the bit
ordinal has up status. See Section 6.3 for details on how an ITR ordinal has up status. See Section 6.3 for details on how an ITR
can determine other ITRs at the site are reachable. When a site can determine other ITRs at the site are reachable. When a site
skipping to change at page 22, line 21 skipping to change at page 22, line 21
packet, in bytes, an ITR would receive from a source inside of packet, in bytes, an ITR would receive from a source inside of
its site. its site.
2. Define L to be the maximum size, in bytes, a packet of size S 2. Define L to be the maximum size, in bytes, a packet of size S
would be after the ITR prepends the LISP header, UDP header, and would be after the ITR prepends the LISP header, UDP header, and
outer network layer header of size H. outer network layer header of size H.
3. Calculate: S + H = L. 3. Calculate: S + H = L.
When an ITR receives a packet from a site-facing interface and adds H When an ITR receives a packet from a site-facing interface and adds H
bytes worth of encapsulation to yield a packet size of L bytes, it bytes worth of encapsulation to yield a packet size greater than L
resolves the MTU issue by first splitting the original packet into 2 bytes, it resolves the MTU issue by first splitting the original
equal-sized fragments. A LISP header is then prepended to each packet into 2 equal-sized fragments. A LISP header is then prepended
fragment. This will ensure that the new, encapsulated packets are of to each fragment. This will ensure that the new, encapsulated
size (S/2 + H), which is always below the effective tunnel MTU. packets are of size (S/2 + H), which is always below the effective
tunnel MTU.
When an ETR receives encapsulated fragments, it treats them as two When an ETR receives encapsulated fragments, it treats them as two
individually encapsulated packets. It strips the LISP headers then individually encapsulated packets. It strips the LISP headers then
forwards each fragment to the destination host of the destination forwards each fragment to the destination host of the destination
site. The two fragments are reassembled at the destination host into site. The two fragments are reassembled at the destination host into
the single IP datagram that was originated by the source host. the single IP datagram that was originated by the source host.
This behavior is performed by the ITR when the source host originates This behavior is performed by the ITR when the source host originates
a packet with the DF field of the IP header is set to 0. When the DF a packet with the DF field of the IP header is set to 0. When the DF
field of the IP header is set to 1, or the packet is an IPv6 packet field of the IP header is set to 1, or the packet is an IPv6 packet
originated by the source host, the ITR will drop the packet when the originated by the source host, the ITR will drop the packet when the
size is greater than L, and sends an ICMP Too Big message to the size is greater than L, and sends an ICMP Too Big message to the
source with a value of S, where S is (L - H). source with a value of S, where S is (L - H).
When the outer header encapsulation uses an IPv4 header the DF bit is When the outer header encapsulation uses an IPv4 header, an
always set to 0. implementation should consider a default behavior of setting the DF
bit to 1 so ETR fragment reassembly can be avoided.
This specification recommends that L be defined as 1500. This specification recommends that L be defined as 1500.
5.4.2. A Stateful Solution to MTU Handling 5.4.2. A Stateful Solution to MTU Handling
An ITR stateful solution to handle MTU issues is describe as follows An ITR stateful solution to handle MTU issues is described as follows
and was first introduced in [OPENLISP]: and was first introduced in [OPENLISP]:
1. The ITR will keep state of the effective MTU for each locator per 1. The ITR will keep state of the effective MTU for each locator per
mapping cache entry. The effective MTU is what the core network mapping cache entry. The effective MTU is what the core network
can deliver along the path between ITR and ETR. can deliver along the path between ITR and ETR.
2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet
with DF bit set to 1, exceeds what the core network can deliver, with DF bit set to 1, exceeds what the core network can deliver,
one of the intermediate routers on the path will send an ICMP Too one of the intermediate routers on the path will send an ICMP Too
Big message to the ITR. The ITR will parse the ICMP message to Big message to the ITR. The ITR will parse the ICMP message to
skipping to change at page 25, line 29 skipping to change at page 25, line 29
The LISP UDP-based messages are the Map-Request and Map-Reply The LISP UDP-based messages are the Map-Request and Map-Reply
messages. When a UDP Map-Request is sent, the UDP source port is messages. When a UDP Map-Request is sent, the UDP source port is
chosen by the sender and the destination UDP port number is set to chosen by the sender and the destination UDP port number is set to
4342. When a UDP Map-Reply is sent, the source UDP port number is 4342. When a UDP Map-Reply is sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking data packet.
The UDP Length field will reflect the length of the UDP header and The UDP Length field will reflect the length of the UDP header and
the LISP Message payload. the LISP Message payload.
The UDP Checksum is computed and set to non-zero for Map-Request and The UDP Checksum is computed and set to non-zero for Map-Request,
Map-Reply messages. It MUST be checked on receipt and if the Map-Reply, Map-Register and ECM control messages. It MUST be checked
checksum fails, the packet MUST be dropped. on receipt and if the checksum fails, the packet MUST be dropped.
LISP-CONS [CONS] use TCP to send LISP control messages. The format LISP-CONS [CONS] use TCP to send LISP control messages. The format
of control messages includes the UDP header so the checksum and of control messages includes the UDP header so the checksum and
length fields can be used to protect and delimit message boundaries. length fields can be used to protect and delimit message boundaries.
This main LISP specification is the authoritative source for message This main LISP specification is the authoritative source for message
format definitions for the Map-Request and Map-Reply messages. format definitions for the Map-Request and Map-Reply messages.
6.1.1. LISP Packet Type Allocations 6.1.1. LISP Packet Type Allocations
skipping to change at page 29, line 11 skipping to change at page 29, line 11
LISP encapsulated the same way from a Map-Server to an ETR. Details LISP encapsulated the same way from a Map-Server to an ETR. Details
on encapsulated Map-Requests and Map-Resolvers can be found in on encapsulated Map-Requests and Map-Resolvers can be found in
[LISP-MS]. [LISP-MS].
Map-Requests MUST be rate-limited. It is recommended that a Map- Map-Requests MUST be rate-limited. It is recommended that a Map-
Request for the same EID-prefix be sent no more than once per second. Request for the same EID-prefix be sent no more than once per second.
An ITR that is configured with mapping database information (i.e. it An ITR that is configured with mapping database information (i.e. it
is also an ETR) may optionally include those mappings in a Map- is also an ETR) may optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request, it may "piggybacked" mapping data receives such a Map-Request and it does
originate a "verifying Map-Request", addressed to the original ITR. not have this mapping in the map-cache, it may originate a "verifying
If the ETR has a map-cache entry that matches the "piggybacked" EID Map-Request", addressed to the map-requesting ITR. If the ETR has a
and the RLOC is in the locator-set for the entry, then it may send map-cache entry that matches the "piggybacked" EID and the RLOC is in
the "verifying Map-Request" to the original Map-Request source. If the locator-set for the entry, then it may send the "verifying Map-
not, then it MUST send it to the "piggybacked" EID. Doing this Request" directly to the originating Map-Request source. If the RLOC
forces the "verifying Map-Request" to go through the mapping database is not in the locator-set, then the ETR MUST send the "verifying Map-
system to reach the authoritative source of information about that Request" to the "piggybacked" EID. Doing this forces the "verifying
EID, guarding against RLOC-spoofing in in the "piggybacked" mapping Map-Request" to go through the mapping database system to reach the
data. authoritative source of information about that EID, guarding against
RLOC-spoofing in in the "piggybacked" mapping data.
6.1.4. Map-Reply Message Format 6.1.4. Map-Reply Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E| Reserved | Record Count | |Type=2 |P|E| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 33 skipping to change at page 33, line 33
earlier Map-Reply. In such a case, the requester updates its cache earlier Map-Reply. In such a case, the requester updates its cache
with the new prefix information and granularity. For example, a with the new prefix information and granularity. For example, a
requester with two cached EID-prefixes that are covered by a Map- requester with two cached EID-prefixes that are covered by a Map-
Reply containing one, less-specific prefix, replaces the entry with Reply containing one, less-specific prefix, replaces the entry with
the less-specific EID-prefix. Note that the reverse, replacement of the less-specific EID-prefix. Note that the reverse, replacement of
one less-specific prefix with multiple more-specific prefixes, can one less-specific prefix with multiple more-specific prefixes, can
also occur but not by removing the less-specific prefix rather by also occur but not by removing the less-specific prefix rather by
adding the more-specific prefixes which during a lookup will override adding the more-specific prefixes which during a lookup will override
the less-specific prefix. the less-specific prefix.
Replies SHOULD be sent for an EID-prefix no more often than once per When an ETR is configured with overlapping EID-prefixes, a Map-
second to the same requesting router. For scalability, it is Request with an EID that longest matches any EID-prefix MUST be
returned in a single Map-Reply message. For instance, if an ETR had
database mapping entries for EID-prefixes:
10.0.0.0/8
10.1.0.0/16
10.1.1.0/24
10.1.2.0/24
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
count of 1 to be returned with a mapping record EID-prefix of
10.1.1.0/24.
A Map-Request for EID 10.1.5.5, would cause a Map-Reply with a record
count of 3 to be returned with mapping records for EID-prefixes
10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.
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
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
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
received later, its Time-to-Live value in the Map-Reply record can be
stored even when other less specifics exist. When a a less specific
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
the map-cache.
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
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.
The addresses for a encapsulated data packets or Map-Request message
are swapped and used for sending the Map-Reply. The UDP source and
destination ports are swapped as well. That is, the source port in
the UDP header for the Map-Reply is set to the well-known UDP port
number 4342.
Map-Reply records can have an empty locator-set. This type of a Map- Map-Reply records can have an empty locator-set. This type of a Map-
Reply is called a Negative Map-Reply. Negative Map-Replies convey Reply is called a Negative Map-Reply. Negative Map-Replies convey
special actions by the sender to the ITR or PTR which have solicited special actions by the sender to the ITR or PTR which have solicited
the Map-Reply. There are two primary applications for Negative Map- the Map-Reply. There are two primary applications for Negative Map-
Replies. The first is for a Map-Resolver to instruct an ITR or PTR Replies. The first is for a Map-Resolver to instruct an ITR or PTR
when a destination is for a LISP site versus a non-LISP site. And when a destination is for a LISP site versus a non-LISP site. And
the other is to source quench Map-Requests which are sent for non- the other is to source quench Map-Requests which are sent for non-
allocated EIDs. allocated EIDs.
For each Map-Reply record, the list of locators in a locator-set MUST For each Map-Reply record, the list of locators in a locator-set MUST
appear in the same order for each ETR that originates a Map-Reply appear in the same order for each ETR that originates a Map-Reply
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
from the source address of the Map-Request or Data-Probe message
which is 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 record in the message. The destination port of a Map-Reply
message is copied from the source port of the Map-Request or Data-
Probe and the source port of the Map-Reply message is set to the
well-known UDP port 4342.
6.1.5.1. Traffic Redirection with Coarse EID-Prefixes
When an ETR is misconfigured or compromised, it could return coarse
EID-prefixes in Map-Reply messages it sends. The EID-prefix could
cover EID-prefixes which are allocated to other sites redirecting
their traffic to the locators of the compromised site.
To solve this problem, there are two basic solutions that could be
used. The first is to have Map-Servers proxy-reply on behalf of ETRs
so their registered EID-prefixes are the ones returned in Map-
Replies. Since the interaction between an ETR and Map-Server is
secured with shared-keys, it is more difficult for an ETR to
misbehave. The second solution is to have ITRs and PTRs cache EID-
prefixes with mask-lengths that are greater than or equal to a
configured prefix length. This limits the damage to a specific width
of any EID-prefix advertised, but needs to be coordinated with the
allocation of site prefixes. These solutions can be used
independently or at the same time.
At the time of this writing, other approaches are being considered
and researched.
6.1.6. Map-Register Message Format 6.1.6. Map-Register Message Format
The usage details of the Map-Register message can be found in The usage details of the Map-Register message can be found in
specification [LISP-MS]. This section solely defines the message specification [LISP-MS]. This section solely defines the message
format. format.
The message is sent in UDP with a destination UDP port of 4342 and a The message is sent in UDP with a destination UDP port of 4342 and a
randomly selected UDP source port number. randomly selected UDP source port number.
The Map-Register message format is: The Map-Register message format is:
skipping to change at page 36, line 25 skipping to change at page 37, line 25
Authentication Data: The message digest used from the output of the Authentication Data: The message digest used from the output of the
Message Authentication Code (MAC) algorithm. The entire Map- Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0. Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field. After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
is recommended. is recommended.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section. However, the record TTL field is not used and set
to 0.
6.1.7. Encapsualted Control Message Format 6.1.7. Encapsualted Control Message Format
An Encapsulated Control Message is used to encapsulate control An Encapsulated Control Message is used to encapsulate control
packets sent between xTRs and the mapping database system described packets sent between xTRs and the mapping database system described
in [LISP-MS]. in [LISP-MS].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 38, line 10 skipping to change at page 39, line 10
and the destination port is 4342. When the control packet is a and the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is Map-Reply, the source port is 4342 and the destination port is
assigned from the source port of the invoking Map-Request. Port assigned from the source port of the invoking Map-Request. Port
number 4341 MUST NOT be assigned to either port. The checksum number 4341 MUST NOT be assigned to either port. The checksum
field MUST be non-zero. field MUST be non-zero.
LCM: The format is one of the control message formats described in LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages and PIM this section. At this time, only Map-Request messages and PIM
Join-Prune messages [MLISP] are allowed to be encapsulated. Join-Prune messages [MLISP] are allowed to be encapsulated.
Encapsulating other types of LISP control messages are for further Encapsulating other types of LISP control messages are for further
study. study. When Map-Requests are sent for RLOC-probing purposes (i.e
the P-bit is set), they MUST not be sent inside Encapsulated
Control Messages.
6.2. Routing Locator Selection 6.2. Routing Locator Selection
Both client-side and server-side may need control over the selection Both client-side and server-side may need control over the selection
of RLOCs for conversations between them. This control is achieved by of RLOCs for conversations between them. This control is achieved by
manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
messages. Alternatively, RLOC information may be gleaned from messages. Alternatively, RLOC information may be gleaned from
received tunneled packets or EID-to-RLOC Map-Request messages. received tunneled packets or EID-to-RLOC Map-Request messages.
The following enumerates different scenarios for choosing RLOCs and The following enumerates different scenarios for choosing RLOCs and
skipping to change at page 45, line 23 skipping to change at page 46, line 23
mappings and inform the sites that are currently communicating with mappings and inform the sites that are currently communicating with
the ETR site using such mappings. the ETR site using such mappings.
When a locator record is added to the end of a locator-set, it is When a locator record is added to the end of a locator-set, it is
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. has cached, it simply ignores them. However, this can only happen
for locator addresses that are lexicographically greater than the
locator addresses in the existing locator-set.
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 address to 0 as well as setting the corresponding set the locator AFI to 0 (indicating an unspecified address), as well
loc-status-bit to 0. This forces ITRs with old or new mappings to as setting the corresponding loc-status-bit to 0. This forces ITRs
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
records appended to the locator-set. At some point, it would be records appended to the locator-set. At some point, it would be
useful to compact the locator-set so the loc-status-bit settings can useful to compact the locator-set so the loc-status-bit settings can
be efficiently packed. be efficiently packed.
We propose here two approaches for locator-set compaction, one We propose here two approaches for locator-set compaction, one
operational and the other a protocol mechanism. The operational operational and the other a protocol mechanism. The operational
approach uses a clock sweep method. The protocol approach uses the approach uses a clock sweep method. The protocol approach uses the
skipping to change at page 57, line 47 skipping to change at page 58, line 47
updates of the database. updates of the database.
The issue of interactions between mobility and LISP needs to be The issue of interactions between mobility and LISP needs to be
explored further. Specific improvements to the entire system will explored further. Specific improvements to the entire system will
depend on the details of mapping mechanisms. Mapping mechanisms depend on the details of mapping mechanisms. Mapping mechanisms
should be evaluated on how well they support session continuity for should be evaluated on how well they support session continuity for
mobile nodes. mobile nodes.
10.5. LISP Mobile Node Mobility 10.5. LISP Mobile Node Mobility
An mobile device can use the LISP infrastructure to achieve mobility A mobile device can use the LISP infrastructure to achieve mobility
by implementing the LISP encapsulation and decapsulation functions by implementing the LISP encapsulation and decapsulation functions
and acting as a simple ITR/ETR. By doing this, such a "LISP mobile and acting as a simple ITR/ETR. By doing this, such a "LISP mobile
node" can use topologically-independent EID IP addresses that are not node" can use topologically-independent EID IP addresses that are not
advertised into and do not impose a cost on the global routing advertised into and do not impose a cost on the global routing
system. These EIDs are maintained at the edges of the mapping system system. These EIDs are maintained at the edges of the mapping system
(in LISP Map-Servers and Map-Resolvers) and are provided on demand to (in LISP Map-Servers and Map-Resolvers) and are provided on demand to
only the correspondents of the LISP mobile node. only the correspondents of the LISP mobile node.
Refer to the LISP Mobility Architecture specification [LISP-MN] for Refer to the LISP Mobility Architecture specification [LISP-MN] for
more details. more details.
skipping to change at page 62, line 10 skipping to change at page 63, line 10
5. Implement the LISP Mobile Node draft [LISP-MN]. 5. Implement the LISP Mobile Node draft [LISP-MN].
6. Research more on how policy affects what gets returned in a Map- 6. Research more on how policy affects what gets returned in a Map-
Reply from an ETR. Reply from an ETR.
7. Continue to experiment with mixed locator-sets to understand how 7. Continue to experiment with mixed locator-sets to understand how
LISP can help the IPv4 to IPv6 transition. LISP can help the IPv4 to IPv6 transition.
8. Add more robustness to locator reachability between LISP sites. 8. Add more robustness to locator reachability between LISP sites.
9. Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF
avoidance, IPv6 connectivity, and LISP-MN.
As of this writing the following accomplishments have been achieved: As of this writing the following accomplishments have been achieved:
1. A unit- and system-tested software switching implementation has 1. A unit- and system-tested software switching implementation has
been completed on cisco NX-OS for this draft for both IPv4 and been completed on cisco NX-OS for this draft for both IPv4 and
IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.
2. A unit- and system-tested software switching implementation on 2. A unit- and system-tested software switching implementation on
cisco NX-OS has been completed for draft [ALT]. cisco NX-OS has been completed for draft [ALT].
3. A unit- and system-tested software switching implementation on 3. A unit- and system-tested software switching implementation on
cisco NX-OS has been completed for draft [INTERWORK]. Support cisco NX-OS has been completed for draft [INTERWORK]. Support
for IPv4 translation is provided and PTR support for IPv4 and for IPv4 translation is provided and PTR support for IPv4 and
IPv6 is provided. IPv6 is provided.
4. The cisco NX-OS implementation supports an experimental 4. The cisco NX-OS implementation supports an experimental
mechanism for slow mobility. mechanism for slow mobility.
5. Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and 5. There are 5 LISP implementations that exist and the first 4
below have gone through interoperability testing at IETF
Hiroshima, based on the draft-ietf-lisp-05.txt spec:
1. cisco NX-OS
2. OpenLISP
3. LISP-Click
4. ZLisp
5. cisco IOS
6. Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and
Andrew Partan continue to test all the features described above Andrew Partan continue to test all the features described above
on a dual-stack infrastructure. on a dual-stack infrastructure.
6. Darrel Lewis and Dave Meyer have deployed both LISP translation 7. Darrel Lewis and Dave Meyer have deployed both LISP translation
and LISP PTR support in the pilot network. Point your browser and LISP PTR support in the pilot network. Point your browser
to http://www.lisp4.net to see translation happening in action to http://www.lisp4.net to see translation happening in action
so your non-LISP site can access a web server in a LISP site. so your non-LISP site can access a web server in a LISP site.
7. Soon http://www.lisp6.net will work where your IPv6 LISP site 8. Soon http://www.lisp6.net will work where your IPv6 LISP site
can talk to a IPv6 web server in a LISP site by using mixed can talk to a IPv6 web server in a LISP site by using mixed
address-family based locators. address-family based locators.
8. An public domain implementation of LISP is underway. See 9. An public domain implementation of LISP is underway. See
[OPENLISP] for details. [OPENLISP] for details.
9. We have deployed Map-Resolvers and Map-Servers on the LISP pilot 10. We have deployed Map-Resolvers and Map-Servers on the LISP pilot
network to gather experience with [LISP-MS]. The first layer of network to gather experience with [LISP-MS]. The first layer of
the architecture are the xTRs which use Map-Servers for EID- the architecture are the xTRs which use Map-Servers for EID-
prefix registration and Map-Resolvers for EID-to-RLOC mapping prefix registration and Map-Resolvers for EID-to-RLOC mapping
resolution. The second layer are the Map-Resolvers and Map- resolution. The second layer are the Map-Resolvers and Map-
Servers which connect to the ALT BGP peering infrastructure. Servers which connect to the ALT BGP peering infrastructure.
And the third layer are ALT-routers which aggregate EID-prefixes And the third layer are ALT-routers which aggregate EID-prefixes
and forward Map-Requests. and forward Map-Requests.
10. A cisco IOS implementation is underway which currently supports 11. A cisco IOS implementation is underway which currently supports
IPv4 encapsulation and decapsulation features. IPv4 encapsulation and decapsulation features.
11. A LISP router based LIG implementation is supported, deployed, 12. A LISP router based LIG implementation is supported, deployed,
and used daily to debug and test the LISP pilot network. See and used daily to debug and test the LISP pilot network. See
[LIG] for details. [LIG] for details.
12. A Linux implementation of LIG has been made available and 13. A Linux implementation of LIG has been made available and
supported by Dave Meyer. It can be run on any Linux system supported by Dave Meyer. It can be run on any Linux system
which resides in either a LISP site or non-LISP site. See [LIG] which resides in either a LISP site or non-LISP site. See [LIG]
for details. Public domain code can be downloaded from for details. Public domain code can be downloaded from
http://github.com/davidmeyer/lig/tree/master. http://github.com/davidmeyer/lig/tree/master.
13. An experimental implementation has been written for three 14. An experimental implementation has been written for three
locator reachability algorithms. Two are the Echo-Noncing and locator reachability algorithms. Two are the Echo-Noncing and
RLOC-Probing algorithms which are documented in this RLOC-Probing algorithms which are documented in this
specification. The third is called TCP-counts which will be specification. The third is called TCP-counts which will be
documented in future drafts. documented in future drafts.
14. The LISP pilot network has been converted from using MD5 HMAC 15. The LISP pilot network has been converted from using MD5 HMAC
authentication for Map-Register messages to SHA-1 HMAC authentication for Map-Register messages to SHA-1 HMAC
authentication. ETRs send with SHA-1 but Map-Servers can authentication. ETRs send with SHA-1 but Map-Servers can
received from either for compatibility purposes. received from either for compatibility purposes.
If interested in writing a LISP implementation, testing any of the If interested in writing a LISP implementation, testing any of the
LISP implementations, or want to be part of the LISP pilot program, LISP implementations, or want to be part of the LISP pilot program,
please contact lisp@ietf.org. please contact lisp@ietf.org.
14. References 14. References
skipping to change at page 65, line 24 skipping to change at page 66, line 24
Packets"", draft-eubanks-chimento-6man-00.txt (work in Packets"", draft-eubanks-chimento-6man-00.txt (work in
progress), February 2009. progress), February 2009.
14.2. Informative References 14.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/numbers.html, 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-01.txt (work in progress), May 2009. draft-ietf-lisp-alt-02.txt (work in progress),
January 2010.
[APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
L. Zhang, "APT: A Practical Transit Mapping Service", L. Zhang, "APT: A Practical Transit Mapping Service",
draft-jen-apt-01.txt (work in progress), November 2007. draft-jen-apt-01.txt (work in progress), November 2007.
[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 66, line 6 skipping to change at page 67, line 8
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00.txt (work in progress), draft-curran-lisp-emacs-00.txt (work in progress),
November 2007. November 2007.
[GSE] "GSE - An Alternate Addressing Architecture for IPv6", [GSE] "GSE - An Alternate Addressing Architecture for IPv6",
draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.
[INTERWORK] [INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-00.txt (work in progress), draft-ietf-lisp-interworking-01.txt (work in progress),
January 2009. January 2010.
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-farinacci-lisp-lig-01.txt (work in progress), draft-farinacci-lisp-lig-01.txt (work in progress),
May 2009. May 2009.
[LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
"Renumbering: Threat or Menace?", Usenix , September 1996. "Renumbering: Threat or Menace?", Usenix , September 1996.
[LISP-MAIN] [LISP-MAIN]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
skipping to change at page 68, line 29 skipping to change at page 69, line 29
They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
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, Roger Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger
Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret
Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, and Jari Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
Arkko. Gregg Schudel, Srinivas Subramanian, Amit Jain, and Xu Xiaohu.
In particular, we would like to thank Dave Meyer for his clever In particular, we would like to thank Dave Meyer for his clever
suggestion for the name "LISP". ;-) suggestion for the name "LISP". ;-)
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-05.txt B.1. Changes to draft-ietf-lisp-06.txt
Editorial based changes:
o Posted December 2009.
o Fix typo for rflags in LISP data header. Changed from "4" to "5".
o Add text to indicate that Map-Register messages must contain a
computed UDP checksum.
o Add definitions for PITR and PETR.
o Indicate an AFI value of 0 is an unspecified address.
o Indicate that the TTL field of a Map-Register is not used and set
to 0 by the sender. This change makes this spec consistent with
[LISP-MS].
o Change "... yield a packet size of L bytes" to "... yield a packet
size greater than L bytes".
o Clarify section 6.1.5 on what addresses and ports are used in Map-
Reply messages.
o Clarify that LSBs that go beyond the number of locators do not to
be SMRed when the locator addresses are greater lexicographically
than the locator in the existing locator-set.
o Add Gregg, Srini, and Amit to acknowledgment section.
o Clarify in the definition of a LISP header what is following the
UDP header.
o Clarify "verifying Map-Request" text in section 6.1.3.
o Add Xu Xiaohu to the acknowledgment section for introducing the
problem of overlapping EID-prefixes among multiple sites in an RRG
email message.
Design based changes:
o Use stronger language to have the outer IPv4 header set DF=1 so we
can avoid fragment reassembly in an ETR or PETR. This will also
make IPv4 and IPv6 encapsulation have consistent behavior.
o Map-Requests should not be sent in ECM with the Probe bit is set.
These type of Map-Requests are used as RLOC-probes and are sent
directly to locator addresses in the underlying network.
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
configure.
o Add text in a new subsection of section 6.1.5 about dealing with
Map-Replies with coarse EID-prefixes.
B.2. 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 69, line 35 skipping to change at page 71, line 44
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.2. Changes to draft-ietf-lisp-04.txt B.3. 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?
o Add Fred Templin in ack section. o Add Fred Templin in acknowledgment section.
o Add Margaret and Sam to the ack section for their great comments. o Add Margaret and Sam to the acknowledgment section for their great
comments.
o Say more about LAGs in the UDP section per Sam Hartman's comment. o Say more about LAGs in the UDP section per Sam Hartman's comment.
o Sam wants to use MAY instead of SHOULD for ignoring checksums on o Sam wants to use MAY instead of SHOULD for ignoring checksums on
ETR. From the mailing list: "You'd need to word it as an ITR MAY ETR. From the mailing list: "You'd need to word it as an ITR MAY
send a zero checksum, an ETR MUST accept a 0 checksum and MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY
ignore the checksum completely. And of course we'd need to ignore the checksum completely. And of course we'd need to
confirm that can actually be implemented. In particular, hardware confirm that can actually be implemented. In particular, hardware
that verifies UDP checksums on receive needs to be checked to make that verifies UDP checksums on receive needs to be checked to make
sure it permits 0 checksums." sure it permits 0 checksums."
skipping to change at page 70, line 26 skipping to change at page 72, line 35
o Fix description in Map-Request section. Where we describe Map- o Fix description in Map-Request section. Where we describe Map-
Reply Record, change "R-bit" to "M-bit". Reply Record, change "R-bit" to "M-bit".
o Add the mobility bit to Map-Replies. So PTRs don't probe so often o Add the mobility bit to Map-Replies. So PTRs don't probe so often
for MNs but often enough to get mapping updates. for MNs but often enough to get mapping updates.
o Indicate SHA1 can be used as well for Map-Registers. o Indicate SHA1 can be used as well for Map-Registers.
o More Fred comments on MTU handling. o More Fred comments on MTU handling.
o Isidor comment about specing better periodic Map-Registers. Will o Isidor comment about spec'ing better periodic Map-Registers. Will
be fixed in draft-ietf-lisp-ms-02.txt. be fixed in draft-ietf-lisp-ms-02.txt.
o Margaret's comment on gleaning: "The current specification does o Margaret's comment on gleaning: "The current specification does
not make it clear how long gleaned map entries should be retained not make it clear how long gleaned map entries should be retained
in the cache, nor does it make it clear how/ when they will be in the cache, nor does it make it clear how/ when they will be
validated. The LISP spec should, at the very least, include a validated. The LISP spec should, at the very least, include a
(short) default lifetime for gleaned entries, require that they be (short) default lifetime for gleaned entries, require that they be
validated within a short period of time, and state that a new validated within a short period of time, and state that a new
gleaned entry should never overwrite an entry that was obtained gleaned entry should never overwrite an entry that was obtained
from the mapping system. The security implications of storing from the mapping system. The security implications of storing
skipping to change at page 71, line 25 skipping to change at page 73, line 35
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.3. Changes to draft-ietf-lisp-03.txt B.4. 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 JohnZ in Echo-Nonce section. o Clarification text from John Zwiebel in Echo-Nonce section.
B.4. Changes to draft-ietf-lisp-02.txt B.5. 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 draft-meyer-lisp-mn-00.txt. o Added to Mobility section to reference draft-meyer-lisp-mn-00.txt.
B.5. Changes to draft-ietf-lisp-01.txt B.6. 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.6. Changes to draft-ietf-lisp-00.txt B.7. 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. 50 change blocks. 
135 lines changed or deleted 290 lines changed or added

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