draft-ietf-lisp-06.txt   draft-ietf-lisp-07.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: July 30, 2010 D. Lewis Expires: October 27, 2010 D. Lewis
cisco Systems cisco Systems
January 25, 2010 April 25, 2010
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-06.txt draft-ietf-lisp-07
Abstract Abstract
This draft describes a simple, incremental, network-based protocol to This draft describes a simple, incremental, network-based protocol to
implement separation of Internet addresses into Endpoint Identifiers implement separation of Internet addresses into Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). This mechanism requires no (EIDs) and Routing Locators (RLOCs). This mechanism requires no
changes to host stacks and no major changes to existing database changes to host stacks and no major changes to existing database
infrastructures. The proposed protocol can be implemented in a infrastructures. The proposed protocol can be implemented in a
relatively small number of routers. relatively small number of routers.
skipping to change at page 1, line 47 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 July 24, 2010. This Internet-Draft will expire on October 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22
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 . . . . . . . . . 23
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 25
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 27
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 27
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 30 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 29
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 33 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 31
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 35 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 34
6.1.7. Encapsualted Control Message Format . . . . . . . . . 37 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 37
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 39 6.1.7. Encapsulated Control Message Format . . . . . . . . . 38
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 40 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 40
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 43 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 41
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 44 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 44
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 45 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 45
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 46 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 46
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 46 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 47
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 47 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 47
7. Router Performance Considerations . . . . . . . . . . . . . . 49 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 48
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 50 6.5.3. Database Map Versioning . . . . . . . . . . . . . . . 49
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 51 7. Router Performance Considerations . . . . . . . . . . . . . . 51
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 51 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 52
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 52 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 53
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 53 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 53
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 54 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 54
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 54 8.4. LISP Functionality with Conventional NATs . . . . . . . . 54
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 54 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 55
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 56 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 56
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 56 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 56
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 56
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 56 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 58
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 58 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 58
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 58 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 58
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 60 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 58
12. Security Considerations . . . . . . . . . . . . . . . . . . . 61 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 60
13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 62 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 60
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 62
14.1. Normative References . . . . . . . . . . . . . . . . . . . 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 63
14.2. Informative References . . . . . . . . . . . . . . . . . . 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 69 14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 65
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.1. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . . 68
B.2. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 71 15.2. Informative References . . . . . . . . . . . . . . . . . . 69
B.3. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 73
B.4. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 73 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 74
B.5. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 74 B.1. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 74
B.6. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 74 B.2. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 75
B.7. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 74 B.3. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 B.4. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 77
B.5. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 79
B.6. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 79
B.7. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 79
B.8. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81
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 5, line 50 skipping to change at page 5, line 50
will be possible for a host (or a collection of hosts) to move to will be possible for a host (or a collection of hosts) to move to
a different point in the network topology either retaining its a different point in the network topology either retaining its
home-based address or acquiring a new address based on the new home-based address or acquiring a new address based on the new
network location. A new network location could be a physically network location. A new network location could be a physically
different point in the network topology or the same physical different point in the network topology or the same physical
point of the topology with a different provider. point of the topology with a different provider.
This draft describes protocol mechanisms to achieve the desired This draft describes protocol mechanisms to achieve the desired
functional separation. For flexibility, the mechanism used for functional separation. For flexibility, the mechanism used for
forwarding packets is decoupled from that used to determine EID to forwarding packets is decoupled from that used to determine EID to
RLOC mappings. This document covers the former. For the later, see RLOC mappings. This document covers the former. For the latter, see
[CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response [CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response
to and intended to address the problem statement that came out of the to and intended to address the problem statement that came out of the
RAWS effort [RFC4984]. RAWS effort [RFC4984].
The Routing and Addressing problem statement can be found in [RADIR]. The Routing and Addressing problem statement can be found in [RADIR].
This draft focuses on a router-based solution. Building the solution This draft focuses on a router-based solution. Building the solution
into the network will facilitate incremental deployment of the into the network will facilitate incremental deployment of the
technology on the Internet. Note that while the detailed protocol technology on the Internet. Note that while the detailed protocol
specification and examples in this document assume IP version 4 specification and examples in this document assume IP version 4
(IPv4), there is nothing in the design that precludes use of the same (IPv4), there is nothing in the design that precludes use of the same
techniques and mechanisms for IPv6. It should be possible for IPv4 techniques and mechanisms for IPv6. It should be possible for IPv4
packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4
RLOCs. RLOCs.
Related work on host-based solutions is described in Shim6 [SHIM6] Related work on host-based solutions is described in Shim6 [RFC5533]
and HIP [RFC4423]. Related work on a router-based solution is and HIP [RFC4423]. Related work on a router-based solution is
described in [GSE]. This draft attempts to not compete or overlap described in [GSE]. This draft attempts to not compete or overlap
with such solutions and the proposed protocol changes are expected to with such solutions and the proposed protocol changes are expected to
complement a host-based mechanism when Traffic Engineering complement a host-based mechanism when Traffic Engineering
functionality is desired. functionality is desired.
Some of the design goals of this proposal include: Some of the design goals of this proposal include:
1. Require no hardware or software changes to end-systems (hosts). 1. Require no hardware or software changes to end-systems (hosts).
skipping to change at page 7, line 8 skipping to change at page 7, line 8
7. Avoid or minimize packet loss when EID-to-RLOC mappings need to 7. Avoid or minimize packet loss when EID-to-RLOC mappings need to
be performed. be performed.
There are 4 variants of LISP, which differ along a spectrum of strong There are 4 variants of LISP, which differ along a spectrum of strong
to weak dependence on the topological nature and possible need for to weak dependence on the topological nature and possible need for
routability of EIDs. The variants are: routability of EIDs. The variants are:
LISP 1: uses EIDs that are routable through the RLOC topology for LISP 1: uses EIDs that are routable through the RLOC topology for
bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as
a prototyping mechanism for early protocol implementation. It is a prototyping mechanism for early protocol implementation. It is
now deprecated and should not be deployed. now deprecated and SHOULD NOT be deployed.
LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC
mappings; such routing is via a separate topology. mappings; such routing is via a separate topology.
LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are
implemented within the DNS. [LISP2] implemented within the DNS. [LISP2]
LISP 3: uses non-routable EIDs that are used as lookup keys for a LISP 3: uses non-routable EIDs that are used as lookup keys for a
new EID-to-RLOC mapping database. Use of Distributed Hash Tables new EID-to-RLOC mapping database. Use of Distributed Hash Tables
[DHTs] [LISPDHT] to implement such a database would be an area to [DHTs] [LISPDHT] to implement such a database would be an area to
skipping to change at page 10, line 29 skipping to change at page 10, line 29
stores, tracks, and is responsible for timing-out and otherwise stores, tracks, and is responsible for timing-out and otherwise
validating EID-to-RLOC mappings. This cache is distinct from the validating EID-to-RLOC mappings. This cache is distinct from the
full "database" of EID-to-RLOC mappings, it is dynamic, local to full "database" of EID-to-RLOC mappings, it is dynamic, local to
the ITR(s), and relatively small while the database is the ITR(s), and relatively small while the database is
distributed, relatively static, and much more global in scope. distributed, relatively static, and much more global in scope.
EID-to-RLOC Database: a global distributed database that contains EID-to-RLOC Database: a global distributed database that contains
all known EID-prefix to RLOC mappings. Each potential ETR all known EID-prefix to RLOC mappings. Each potential ETR
typically contains a small piece of the database: the EID-to-RLOC typically contains a small piece of the database: the EID-to-RLOC
mappings for the EID prefixes "behind" the router. These map to mappings for the EID prefixes "behind" the router. These map to
one of the router's own, globally-visible, IP addresses. one of the router's own, globally-visible, IP addresses. The same
database mapping entries MUST be configured on all ETRs for a
given site. That is, the EID-prefixes for the site and locator-
set for each EID-prefix MUST be the same on all ETRs so they
consistently send Map-Reply messages with the same database
mapping contents.
Recursive Tunneling: when a packet has more than one LISP IP Recursive Tunneling: when a packet has more than one LISP IP
header. Additional layers of tunneling may be employed to header. Additional layers of tunneling may be employed to
implement traffic engineering or other re-routing as needed. When implement traffic engineering or other re-routing as needed. When
this is done, an additional "outer" LISP header is added and the this is done, an additional "outer" LISP header is added and the
original RLOCs are preserved in the "inner" header. Any original RLOCs are preserved in the "inner" header. Any
references to tunnels in this specification refers to dynamic references to tunnels in this specification refers to dynamic
encapsulating tunnels and never are they statically configured. encapsulating tunnels and never are they statically configured.
Reencapsulating Tunnels: when a packet has no more than one LISP IP Reencapsulating Tunnels: when a packet has no more than one LISP IP
skipping to change at page 11, line 10 skipping to change at page 11, line 11
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-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 Indicator (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] for details. An AFI value of 0 IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An
used in this specification indicates an unspecified encoded AFI value of 0 used in this specification indicates an unspecified
address where the the length of the address is 0 bytes following encoded address where the the length of the address is 0 bytes
the 16-bit AFI value of 0. 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
skipping to change at page 12, line 5 skipping to change at page 11, line 43
design for details. design for details.
Proxy ITR (PITR): also known as a PTR is defined and described in 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- [INTERWORK], a PITR acts like an ITR but does so on behalf of non-
LISP sites which send packets to destinations at LISP sites. LISP sites which send packets to destinations at LISP sites.
Proxy ETR (PETR): is defined and described in [INTERWORK], a PETR 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 acts like an ETR but does so on behalf of LISP sites which send
packets to destinations at non-LISP sites. packets to destinations at non-LISP sites.
Route-returnability: is an assumption that the underlying routing
system will deliver packets to the destination. When combined
with a nonce that is provided by a sender and returned by a
receiver limits off-path data insertion.
LISP site: is a set of routers in an edge network that are under a
single technical administration. LISP routers which reside in the
edge network are the demarcation points to separate the edge
network from the core network.
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 25 skipping to change at page 13, line 25
facilitate scaling of the EID-to-RLOC mapping database. The facilitate scaling of the EID-to-RLOC mapping database. The
hierarchy is based on a address allocation hierarchy which is not hierarchy is based on a address allocation hierarchy which is not
dependent on the network topology. dependent on the network topology.
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 flowing 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 a TE-ETR within the uses for the new prepended header would be either a TE-ETR within the
ISP (along intra-ISP traffic engineered path) or a TE-ETR within ISP (along intra-ISP traffic engineered path) or a TE-ETR within
another ISP (an inter-ISP traffic engineered path, where an agreement another ISP (an inter-ISP traffic engineered path, where an 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
skipping to change at page 14, line 19 skipping to change at page 14, line 19
o Source host "host1.abc.com" is sending a packet to o Source host "host1.abc.com" is sending a packet to
"host2.xyz.com", exactly what host1 would do if the site was not "host2.xyz.com", exactly what host1 would do if the site was not
using LISP. using LISP.
o Each site is multi-homed, so each tunnel router has an address o Each site is multi-homed, so each tunnel router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular tunnel router is attached. provider to which that particular tunnel router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively. destination, respectively, but the source and destination can be
located anywhere in LISP site.
o Data Probes are used to solicit Map-Replies versus using Map- o Map-Requests can be sent on the underlying routing system topology
Requests. And the Data Probes are sent on the underlying topology (LISP 1.0) or over an alternative topology [ALT].
(the LISP 1.0 variant) but could also be sent over an alternative
topology (the LISP 1.5 variant) as it would in [ALT]. o Map-Replies are sent on the underlying routing system topology.
Client host1.abc.com wants to communicate with server host2.xyz.com: Client host1.abc.com wants to communicate with server host2.xyz.com:
1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 1. host1.abc.com wants to open a TCP connection to host2.xyz.com.
It does a DNS lookup on host2.xyz.com. An A/AAAA record is It does a DNS lookup on host2.xyz.com. An A/AAAA record is
returned. This address is used as the destination EID and the returned. This address is the destination EID. The locally-
locally-assigned address of host1.abc.com is used as the source assigned address of host1.abc.com is used as the source EID. An
EID. An IPv4 or IPv6 packet is built using the EIDs in the IPv4 IPv4 or IPv6 packet is built and forwarded through the LISP site
or IPv6 header and sent to the default router. as a normal IP packet until it reaches a LISP ITR.
2. The default router is configured as an ITR. The ITR must be able 2. The LISP ITR must be able to map the EID destination to an RLOC
to map the EID destination to an RLOC of the ETR at the of one of the ETRs at the destination site. The specific method
destination site. The ITR prepends a LISP header to the packet, used to do this is not described in this example. See [ALT] or
with one of its RLOCs as the source IPv4 or IPv6 address. The [CONS] for possible solutions.
destination EID from the original packet header is used as the
destination IPv4 or IPv6 in the prepended LISP header.
Subsequent packets, where the outer destination address is the
destination EID will be sent until EID-to-RLOC mapping is
learned.
3. In LISP 1, the packet is routed through the Internet as it is 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
today. In LISP 1.5, the packet is routed on a different topology rate-limited.
which may have EID prefixes distributed and advertised in an
aggregatable fashion. In either case, the packet arrives at the
ETR. The router is configured to "punt" the packet to the
router's processor. See Section 7 for more details. For LISP
2.0 and 3.0, the behavior is not fully defined yet.
4. The LISP header is stripped so that the packet can be forwarded 4. In LISP 1.0, the Map-Request packet is routed through the
by the router control plane. The router looks up the destination underlying routing system. In LISP 1.5, the Map-Request packet
EID in the router's EID-to-RLOC database (not the cache, but the is routed on an alternate logical topology. In either case, when
configured data structure of RLOCs). An EID-to-RLOC Map-Reply the Map-Request arrives at one of the ETRs at the destination
message is originated by the ETR and is addressed to the source site, it will process the packet as a control message.
RLOC in the LISP header of the original packet (this is the ITR).
The source RLOC of the Map-Reply is one of the ETR's RLOCs.
5. The ITR receives the Map-Reply message, parses the message (to 5. The ETR looks at the destination EID of the Map-Request and
matches it against the prefixes in the ETR's configured EID-to-
RLOC mapping database. This is the list of EID-prefixes the ETR
is supporting for the site it resides in. If there is no match,
the Map-Request is dropped. Otherwise, a LISP Map-Reply is
returned to the ITR.
6. The ITR receives the Map-Reply message, parses the message (to
check for format validity) and stores the mapping information check for format validity) and stores the mapping information
from the packet. This information is put in the ITR's EID-to- from the packet. This information is put in the ITR's EID-to-
RLOC mapping cache (this is the on-demand cache, the cache where RLOC mapping cache (this is the on-demand cache, the cache where
entries time out due to inactivity). entries time out due to inactivity).
6. Subsequent packets from host1.abc.com to host2.xyz.com will have 7. Subsequent packets from host1.abc.com to host2.xyz.com will have
a LISP header prepended by the ITR using the appropriate RLOC as a LISP header prepended by the ITR using the appropriate RLOC as
the LISP header destination address learned from the ETR. Note, the LISP header destination address learned from the ETR. Note,
the packet may be sent to a different ETR than the one which the packet may be sent to a different ETR than the one which
returned the Map-Reply due to the source site's hashing policy or returned the Map-Reply due to the source site's hashing policy or
the destination site's locator-set policy. the destination site's locator-set policy.
7. The ETR receives these packets directly (since the destination 8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), strips the LISP address is one of its assigned IP addresses), strips the LISP
header and forwards the packets to the attached destination host. header and forwards the packets to the attached destination host.
In order to eliminate the need for a mapping lookup in the reverse In order to eliminate the need for a mapping lookup in the reverse
direction, an ETR MAY create a cache entry that maps the source EID direction, an ETR MAY create a cache entry that maps the source EID
(inner header source IP address) to the source RLOC (outer header (inner header source IP address) to the source RLOC (outer header
source IP address) in a received LISP packet. Such a cache entry is source IP address) in a received LISP packet. Such a cache entry is
termed a "gleaned" mapping and only contains a single RLOC for the termed a "gleaned" mapping and only contains a single RLOC for the
EID in question. More complete information about additional RLOCs EID in question. More complete information about additional RLOCs
SHOULD be verified by sending a LISP Map-Request for that EID. Both SHOULD be verified by sending a LISP Map-Request for that EID. Both
skipping to change at page 17, line 24 skipping to change at page 17, line 24
OH | Time to Live | Protocol = 17 | Header Checksum | OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator | | | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator | \ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E| rflags | Nonce | L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Locator Status Bits | S / | Instance ID/Locator Status Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID | | | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID | \ | Destination EID |
skipping to change at page 18, line 34 skipping to change at page 18, line 34
| | | |
^ + Destination Routing Locator + ^ + Destination Routing Locator +
| | | | | |
\ + + \ + +
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E| rflags | Nonce | L |N|L|E|V|I|flags| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Locator Status Bits | S / | Instance ID/Locator Status Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label | / |Version| Traffic Class | Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit | / | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
I + + I + +
n | | n | |
n + Source EID + n + Source EID +
e | | e | |
skipping to change at page 19, line 26 skipping to change at page 19, line 26
addresses are EIDs. addresses are EIDs.
Outer Header: is the outer header prepended by an ITR. The address Outer Header: is the outer header prepended by an ITR. The address
fields contain RLOCs obtained from the ingress router's EID-to- fields contain RLOCs obtained from the ingress router's EID-to-
RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768].
The DF bit of the Flags field is set to 0 when the method in The DF bit of the Flags field is set to 0 when the method in
Section 5.4.1 is used and set to 1 when the method in Section 5.4.1 is used and set to 1 when the method in
Section 5.4.2 is used. Section 5.4.2 is used.
UDP Header: contains a ITR selected source port when encapsulating a UDP Header: contains a ITR selected source port when encapsulating a
packet. See Section 6.4 for details on the hash algorithm used packet. See Section 6.4 for details on the hash algorithm used to
select a source port based on the 5-tuple of the inner header. select a source port based on the 5-tuple of the inner header.
The destination port MUST be set to the well-known IANA assigned The destination port MUST be set to the well-known IANA assigned
port value 4341. port value 4341.
UDP Checksum: this field SHOULD be transmitted as zero by an ITR for UDP Checksum: this field SHOULD be transmitted as zero by an ITR for
either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a
packet with a zero UDP checksum is received by an ETR, the ETR packet with a zero UDP checksum is received by an ETR, the ETR
MUST accept the packet for decapsulation. When an ITR transmits a MUST accept the packet for decapsulation. When an ITR transmits a
non-zero value for the UDP checksum, it MUST send a correctly non-zero value for the UDP checksum, it MUST send a correctly
computed value in this field. When an ETR receives a packet with computed value in this field. When an ETR receives a packet with
skipping to change at page 20, line 8 skipping to change at page 20, line 8
be made to align LISP with the outcome of the broader discussion. be made to align LISP with the outcome of the broader discussion.
UDP Length: for an IPv4 encapsulated packet, the inner header Total UDP Length: for an IPv4 encapsulated packet, the inner header Total
Length plus the UDP and LISP header lengths are used. For an IPv6 Length plus the UDP and LISP header lengths are used. For an IPv6
encapsulated packet, the inner header Payload Length plus the size encapsulated packet, the inner header Payload Length plus the size
of the IPv6 header (40 bytes) plus the size of the UDP and LISP of the IPv6 header (40 bytes) plus the size of the UDP and LISP
headers are used. The UDP header length is 8 bytes. headers are used. The UDP header length is 8 bytes.
N: this is the nonce-present bit. When this bit is set to 1, the N: this is the nonce-present bit. When this bit is set to 1, the
low-order 24-bits of the first 32-bits of the LISP header contains low-order 24-bits of the first 32-bits of the LISP header contains
a Nonce. See section Section 6.3.1 for details. a Nonce. See Section 6.3.1 for details. Both N and V bits MUST
NOT be set in the same packet. If they are, a decapsulating ETR
MUST treat the "Nonce/Map-Version" field as having a Nonce value
present.
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.
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 6.3.1 for
details. details.
rflags: this 5-bit field is reserved for future flag use. It is set V: this is the Map-Version present bit. When this bit is set to 1,
the N bit MUST be 0. Refer to Section 6.5.3 for more details.
This bit indicates that the first 4 bytes of the LISP header is
encoded as:
0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: this is the Instance ID bit. See Section 5.5 for more details.
When this bit is set to 1, the Locator Status Bits field is
reduced to 8-bits and the high-order 24-bits are used as an
Instance ID. If the L-bit is set to 0, then the low-order 8 bits
are transmitted as zero and ignored on receipt. The format of the
last 4 bytes of the LISP header would look like:
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: this 3-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, a remote ITR is either echoing a previously requested is set, a remote ITR is either echoing a previously requested
echo-nonce or providing a random nonce. See section Section 6.3.1 echo-nonce or providing a random nonce. See Section 6.3.1 for
for more details. 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 field. The field is 32-bits when the I-bit is
ITR is indicating to the ETR the RLOC associated with the bit set to 0 and is 8 bits when the I-bit is set to 1. When a Locator
ordinal has up status. See Section 6.3 for details on how an ITR Status Bit is set to 1, the ITR is indicating to the ETR the RLOC
can determine other ITRs at the site are reachable. When a site associated with the bit ordinal has up status. See Section 6.3
has multiple EID-prefixes which result in multiple mappings (where for details on how an ITR can determine the status of other ITRs
each could have a different locator-set), the Locator Status Bits at the same site. When a site has multiple EID-prefixes which
setting in an encapsulated packet MUST reflect the mapping for the result in multiple mappings (where each could have a different
EID-prefix that the inner-header source EID address matches. locator-set), the Locator Status Bits setting in an encapsulated
packet MUST reflect the mapping for the EID-prefix that the inner-
header source EID address matches.
When doing Recursive Tunneling or ITR/PTR encapsulation: When doing Recursive Tunneling or ITR/PTR encapsulation:
o The outer header Time to Live field (or Hop Limit field, in case o The outer header Time to Live field (or Hop Limit field, in case
of IPv6) SHOULD be copied from the inner header Time to Live of IPv6) SHOULD be copied from the inner header Time to Live
field. field.
o The outer header Type of Service field (or the Traffic Class o The outer header Type of Service field (or the Traffic Class
field, in the case of IPv6) SHOULD be copied from the inner header field, in the case of IPv6) SHOULD be copied from the inner header
Type of Service field (with one caveat, see below). Type of Service field (with one caveat, see below).
skipping to change at page 21, line 43 skipping to change at page 22, line 40
to congestion between the tunnel endpoints. to congestion between the tunnel endpoints.
5.4. Dealing with Large Encapsulated Packets 5.4. Dealing with Large Encapsulated Packets
In the event that the MTU issues mentioned above prove to be more In the event that the MTU issues mentioned above prove to be more
serious than expected, this section proposes 2 simple mechanisms to serious than expected, this section proposes 2 simple mechanisms to
deal with large packets. One is stateless using IP fragmentation and deal with large packets. One is stateless using IP fragmentation and
the other is stateful using Path MTU Discovery [RFC1191]. the other is stateful using Path MTU Discovery [RFC1191].
It is left to the implementor to decide if the stateless or stateful It is left to the implementor to decide if the stateless or stateful
mechanism should be implemented. Both or neither can be decided as mechanism SHOULD be implemented. Both or neither can be decided as
well since it is a local decision in the ITR regarding how to deal well since it is a local decision in the ITR regarding how to deal
with MTU issues. Sites can interoperate with differing mechanisms. with MTU issues. Sites can interoperate with differing mechanisms.
Both stateless and stateful mechanisms also apply to Reencapsulating Both stateless and stateful mechanisms also apply to Reencapsulating
and Recursive Tunneling. So any actions reference below to an ITR and Recursive Tunneling. So any actions below referring to an ITR
also apply to an TE-ITR. also apply to an TE-ITR.
5.4.1. A Stateless Solution to MTU Handling 5.4.1. A Stateless Solution to MTU Handling
An ITR stateless solution to handle MTU issues is described as An ITR stateless solution to handle MTU issues is described as
follows: follows:
1. Define an architectural constant S for the maximum size of a 1. Define an architectural constant S for the maximum size of a
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.
skipping to change at page 22, line 42 skipping to change at page 23, line 37
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, an When the outer header encapsulation uses an IPv4 header, an
implementation should consider a default behavior of setting the DF implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
bit to 1 so ETR fragment reassembly can be avoided. can be avoided. An implementation MAY set the DF bit in such headers
to 0 if it has good reason to believe there are unresolvable path MTU
issues between the sending ITR and the receiving ETR.
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 described 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
skipping to change at page 24, line 5 skipping to change at page 24, line 25
stored with the mapping cache entry associated with the stored with the mapping cache entry associated with the
destination EID the packet is for, the ITR will send an ICMP Too destination EID the packet is for, the ITR will send an ICMP Too
Big message back to the source. The packet size advertised by Big message back to the source. The packet size advertised by
the ITR in the ICMP Too Big message is the effective MTU minus the ITR in the ICMP Too Big message is the effective MTU minus
the LISP encapsulation length. the LISP encapsulation length.
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
5.5. Using Virtualization and Segmentation with LISP
When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI based address
unique. See [LCAF] for details for a possible address encoding. The
LCAF encoding is an area for further study.
An Instance ID can be carried in a LISP encapsulated packet. An ITR
that prepends a LISP header, will copy a 24-bit value, used by the
LISP router to uniquely identify the address space. The value is
copied to the Instance ID field of the LISP header and the I-bit is
set to 1.
When an ETR decapsulate a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup.
Some examples of the 24-bit value to copy or map into the Instance ID
field could be a 802.1Q VLAN tag or a configured VRF-ID value.
6. EID-to-RLOC Mapping 6. EID-to-RLOC Mapping
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats
The following new UDP packet types are used to retrieve EID-to-RLOC The following new UDP packet types are used to retrieve EID-to-RLOC
mappings: mappings:
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 26, line 21 skipping to change at page 27, line 21
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
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 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| Reserved | Record Count | |Type=1 |A|M|P|S| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | ITR-AFI | | Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID Address ... | | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating ITR RLOC Address ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-prefix-AFI | / | Reserved | EID mask-len | EID-prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-prefix ... | \ | EID-prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 1 (Map-Request) Type: 1 (Map-Request)
A: This is an authoritative bit, which is set to 0 for UDP-based Map- A: This is an authoritative bit, which is set to 0 for UDP-based Map-
Requests sent by an ITR. Requests sent by an ITR.
M: When set, it indicates a Map-Reply Record segment is included in M: When set, it indicates a Map-Reply Record segment is included in
the Map-Request. the Map-Request.
P: Indicates that a Map-Request should be treated as a "piggyback" P: This is the probe-bit which indicates that a Map-Request SHOULD be
locator reachability probe. The receiver should respond with a treated as a locator reachability probe. The receiver SHOULD
Map-Reply with the P bit set and the nonce copied from the Map- respond with a Map-Reply with the probe-bit set, indicating the
Request. See section Section 6.3.2 for more details. Map-Reply is a locator reachability probe reply, with the nonce
copied from the Map-Request. See Section 6.3.2 for more details.
S: This is the SMR bit. See Section 6.5.2 for details. S: This is the SMR bit. See Section 6.5.2 for details.
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 number
of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this
message. Multiple ITR-RLOC Address 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 31, where IRC value 0 means
an ITR-RLOC address count of 1, an IRC value of 1 means an ITR-
RLOC address count of 2, and so on up to an IRC value of 31, which
means an ITR-RLOC address count of 32.
Record Count: The number of records in this Map-Request message. A Record Count: The number of records in this Map-Request message. A
record is comprised of the portion of the packet that is labeled record is comprised of the portion of the packet that is labeled
'Rec' above and occurs the number of times equal to Record Count. 'Rec' above and occurs the number of times equal to Record Count.
For this version of the protocol, a receiver MUST accept and For this version of the protocol, a receiver MUST accept and
process Map-Requests that contain one or more records, but a process Map-Requests that contain one or more records, but a
sender MUST only send Map-Requests containing one record. Support sender MUST only send Map-Requests containing one record. Support
for requesting multiple EIDs in a single Map-Request message will for requesting multiple EIDs in a single Map-Request message will
be specified in a future version of the protocol. be specified in a future version of the protocol.
Nonce: An 8-byte random value created by the sender of the Map- Nonce: An 8-byte random value created by the sender of the Map-
Request. This nonce will be returned in the Map-Reply. The Request. This nonce will be returned in the Map-Reply. The
security of the LISP mapping protocol depends critically on the security of the LISP mapping protocol depends critically on the
strength of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. The nonce
SHOULD be generated by a properly seeded pseudo-random (or strong SHOULD be generated by a properly seeded pseudo-random (or strong
random) source. See [RFC4086] for advice on generating security- random) source. See [RFC4086] for advice on generating security-
sensitive random data. sensitive random data.
Source-EID-AFI: Address family of the "Source EID Address" field. Source-EID-AFI: Address family of the "Source EID Address" field.
ITR-AFI: Address family of the "Originating ITR RLOC Address" field.
Source EID Address: This is the EID of the source host which Source EID Address: This is the EID of the source host which
originated the packet which is invoking this Map-Request. When originated the packet which is invoking this Map-Request. When
Map-Requests are used for refreshing a map-cache entry or for Map-Requests are used for refreshing a map-cache entry or for
RLOC-probing, the value 0 is used. RLOC-probing, the value 0 is used.
Originating ITR RLOC Address: Used to give the ETR the option of ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that
returning a Map-Reply in the address-family of this locator. follows this field.
ITR-RLOC Address: Used to give the ETR the option of selecting the
destination address from any address family for the Map-Reply
message. This address MUST be a routable RLOC address.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
EID-AFI: Address family of EID-prefix according to [RFC2434] EID-prefix-AFI: Address family of EID-prefix according to [RFC5226]
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. When a Map-Request is sent by an ITR because a address-family. When a Map-Request is sent by an ITR because a
data packet is received for a destination where there is no data packet is received for a destination where there is no
mapping entry, the EID-prefix is set to the destination IP address mapping entry, the EID-prefix is set to the destination IP address
of the data packet. And the 'EID mask-len' is set to 32 or 128 of the data packet. And the 'EID mask-len' is set to 32 or 128
for IPv4 or IPv6, respectively. When an xTR wants to query a site for IPv4 or IPv6, respectively. When an xTR wants to query a site
about the status of a mapping it already has cached, the EID- about the status of a mapping it already has cached, the EID-
prefix used in the Map-Request has the same mask-length as the prefix used in the Map-Request has the same mask-length as the
EID-prefix returned from the site when it sent a Map-Reply EID-prefix returned from the site when it sent a Map-Reply
skipping to change at page 28, line 36 skipping to change at page 29, line 48
Mapping Protocol Data: See [CONS] or [ALT] for details. This field Mapping Protocol Data: See [CONS] or [ALT] for details. This field
is optional and present when the UDP length indicates there is is optional and present when the UDP length indicates there is
enough space in the packet to include it. enough space in the packet to include it.
6.1.3. EID-to-RLOC UDP Map-Request Message 6.1.3. EID-to-RLOC UDP Map-Request Message
A Map-Request is sent from an ITR when it needs a mapping for an EID, A Map-Request is sent from an ITR when it needs a mapping for an EID,
wants to test an RLOC for reachability, or wants to refresh a mapping wants to test an RLOC for reachability, or wants to refresh a mapping
before TTL expiration. For the initial case, the destination IP before TTL expiration. For the initial case, the destination IP
address used for the Map-Request is the destination-EID from the address used for the Map-Request is the destination-EID from the
packet which had a mapping cache lookup failure. For the later 2 packet which had a mapping cache lookup failure. For the latter 2
cases, the destination IP address used for the Map-Request is one of cases, the destination IP address used for the Map-Request is one of
the RLOC addresses from the locator-set of the map cache entry. The the RLOC addresses from the locator-set of the map cache entry. The
source address is either an IPv4 or IPv6 RLOC address depending if source address is either an IPv4 or IPv6 RLOC address depending if
the Map-Request is using an IPv4 versus IPv6 header, respectively. the Map-Request is using an IPv4 versus IPv6 header, respectively.
In all cases, the UDP source port number for the Map-Request message In all cases, the UDP source port number for the Map-Request message
is a randomly allocated 16-bit value and the UDP destination port is a randomly allocated 16-bit value and the UDP destination port
number is set to the well-known destination port number 4342. A number is set to the well-known destination port number 4342. A
successful Map-Reply updates the cached set of RLOCs associated with successful Map-Reply updates the cached set of RLOCs associated with
the EID prefix range. the EID prefix range.
One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
be filled in by the ITR. The number of fields (minus 1) encoded MUST
be placed in the IRC field. The ITR MAY include all locally
configured locators in this list or just provide one locator address
from each address family it supports. If the ITR erroneously
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request.
Map-Requests can also be LISP encapsulated using UDP destination port Map-Requests can also be LISP encapsulated using UDP destination port
4342 with a LISP type value set to "Encapsulated Control Message", 4342 with a LISP type value set to "Encapsulated Control Message",
when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are
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.
skipping to change at page 30, line 20 skipping to change at page 31, line 20
|Type=2 |P|E| Reserved | Record Count | |Type=2 |P|E| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Rsvd | Map-Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: Indicates that the Map-Reply is in response to a "piggyback" P: This is the probe-bit which indicates that the Map-Reply is in
locator reachability Map-Request. The nonce field should contain response to a locator reachability probe Map-Request. The nonce
a copy of the nonce value from the original Map-Request. See field MUST contain a copy of the nonce value from the original
section Section 6.3.2 for more details. Map-Request. See Section 6.3.2 for more details.
E: Indicates that the ETR which sends this Map-Reply message is E: Indicates that the ETR which sends this Map-Reply message is
advertising that the site is enabled for the Echo-Nonce locator advertising that the site is enabled for the Echo-Nonce locator
reachability algorithm. See Section 6.3.1 for more details. reachability algorithm. See Section 6.3.1 for more details.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this reply message. A record Record Count: The number of records in this reply message. A record
is comprised of that portion of the packet labeled 'Record' above is comprised of that portion of the packet labeled 'Record' above
and occurs the number of times equal to Record count. and occurs the number of times equal to Record count.
Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value
from the Map-Request is echoed in this Nonce field of the Map- from the Map-Request is echoed in this Nonce field of the Map-
Reply. Reply.
Record TTL: The time in minutes the recipient of the Map-Reply will Record TTL: The time in minutes the recipient of the Map-Reply will
store the mapping. If the TTL is 0, the entry should be removed store the mapping. If the TTL is 0, the entry SHOULD be removed
from the cache immediately. If the value is 0xffffffff, the from the cache immediately. If the value is 0xffffffff, the
recipient can decide locally how long to store the mapping. recipient can decide locally how long to store the mapping.
Locator Count: The number of Locator entries. A locator entry Locator Count: The number of Locator entries. A locator entry
comprises what is labeled above as 'Loc'. The locator count can comprises what is labeled above as 'Loc'. The locator count can
be 0 indicating there are no locators for the EID-prefix. be 0 indicating there are no locators for the EID-prefix.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
ACT: This 3-bit field describes negative Map-Reply actions. These ACT: This 3-bit field describes negative Map-Reply actions. These
skipping to change at page 31, line 41 skipping to change at page 32, line 41
values are: values are:
(0) Drop: The packet is dropped silently. (0) Drop: The packet is dropped silently.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent by a UDP-based message is always
set by the ETR. See [CONS] for TCP-based Map-Replies. set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a
Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
Authoritative bit is set to 0. This indicates to requesting ITRs
that the Map-Reply was not originated by a LISP node managed at
the site that owns the EID-prefix.
EID-AFI: Address family of EID-prefix according to [RFC2434]. Map-Version Number: When this 12-bit value is non-zero the Map-Reply
sender is informing the ITR what the version number is for the
EID-record contained in the Map-Reply. The ETR can allocate this
number internally but MUST coordinate this value with other ETRs
for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Section 6.5.3 for more
details.
EID-AFI: Address family of EID-prefix according to [RFC5226].
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. address-family.
Priority: each RLOC is assigned a unicast priority. Lower values Priority: each RLOC is assigned a unicast priority. Lower values
are more preferable. When multiple RLOCs have the same priority, are more preferable. When multiple RLOCs have the same priority,
they may be used in a load-split fashion. A value of 255 means they may be used in a load-split fashion. A value of 255 means
the RLOC MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast forwarding.
Weight: when priorities are the same for multiple RLOCs, the weight Weight: when priorities are the same for multiple RLOCs, the weight
indicates how to balance unicast traffic between them. Weight is indicates how to balance unicast traffic between them. Weight is
encoded as a percentage of total unicast packets that match the encoded as a percentage of total unicast packets that match the
mapping entry. If a non-zero weight value is used for any RLOC, mapping entry. If a non-zero weight value is used for any RLOC,
then all RLOCs must use a non-zero weight value and then the sum then all RLOCs MUST use a non-zero weight value and then the sum
of all weight values MUST equal 100. If a zero value is used for of all weight values MUST equal 100. If a zero value is used for
any RLOC weight, then all weights MUST be zero and the receiver of any RLOC weight, then all weights MUST be zero and the receiver of
the Map-Reply will decide how to load-split traffic. See the Map-Reply will decide how to load-split traffic. See
Section 6.4 for a suggested hash algorithm to distribute load Section 6.4 for a suggested hash algorithm to distribute load
across locators with same priority and equal weight values. When across locators with same priority and equal weight values. When
a single RLOC exists in a mapping entry, the weight value MUST be a single RLOC exists in a mapping entry, the weight value MUST be
set to 100 and ignored on receipt. set to 100 and ignored on receipt.
M Priority: each RLOC is assigned a multicast priority used by an M Priority: each RLOC is assigned a multicast priority used by an
ETR in a receiver multicast site to select an ITR in a source ETR in a receiver multicast site to select an ITR in a source
multicast site for building multicast distribution trees. A value multicast site for building multicast distribution trees. A value
of 255 means the RLOC MUST NOT be used for joining a multicast of 255 means the RLOC MUST NOT be used for joining a multicast
distribution tree. distribution tree.
M Weight: when priorities are the same for multiple RLOCs, the M Weight: when priorities are the same for multiple RLOCs, the
weight indicates how to balance building multicast distribution weight indicates how to balance building multicast distribution
trees across multiple ITRs. The weight is encoded as a percentage trees across multiple ITRs. The weight is encoded as a percentage
of total number of trees build to the source site identified by of total number of trees build to the source site identified by
the EID-prefix. If a non-zero weight value is used for any RLOC, the EID-prefix. If a non-zero weight value is used for any RLOC,
then all RLOCs must use a non-zero weight value and then the sum then all RLOCs MUST use a non-zero weight value and then the sum
of all weight values MUST equal 100. If a zero value is used for of all weight values MUST equal 100. If a zero value is used for
any RLOC weight, then all weights MUST be zero and the receiver of any RLOC weight, then all weights MUST be zero and the receiver of
the Map-Reply will decide how to distribute multicast state across the Map-Reply will decide how to distribute multicast state across
ITRs. ITRs.
Unused Flags: set to 0 when sending and ignored on receipt. Unused Flags: set to 0 when sending and ignored on receipt.
L: when this bit is set, the locator is flagged as a local locator to
the ETR that is sending the Map-Reply. When a Map-Server is doing
proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
0 for all locators in this locator-set.
p: when this bit is set, an ETR informs the RLOC-probing ITR that the
locator address, for which this bit is set, is the one being RLOC-
probed and may be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular locator, MUST use
this locator for retrieving the data structure used to store the
fact that the locator is reachable. The "p" bit is set for a
single locator in the same locator set. If an implementation sets
more than one "p" bit erroneously, the receiver of the Map-Reply
MUST select the first locator. The "p" bit MUST NOT be set for
locator-set records sent in Map-Request and Map-Register messages.
R: when this bit is set, the locator is known to be reachable from R: when this bit is set, the locator is known to be reachable from
the Map-Reply sender's perspective. the Map-Reply sender's perspective.
Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
assigned to an ETR or router acting as a proxy replier for the assigned to an ETR or router acting as a proxy replier for the
EID-prefix. Note that the destination RLOC address MAY be an EID-prefix. Note that the destination RLOC address MAY be an
anycast address. A source RLOC can be an anycast address as well. anycast address. A source RLOC can be an anycast address as well.
The source or destination RLOC MUST NOT be the broadcast address The source or destination RLOC MUST NOT be the broadcast address
(255.255.255.255 or any subnet broadcast address known to the (255.255.255.255 or any subnet broadcast address known to the
router), and MUST NOT be a link-local multicast address. The router), and MUST NOT be a link-local multicast address. The
skipping to change at page 34, line 13 skipping to change at page 35, line 40
10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. 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 Note that not all overlapping EID-prefixes need to be returned, only
the more specifics (note in the second example above 10.0.0.0/8 was the more specifics (note in the second example above 10.0.0.0/8 was
not returned for requesting EID 10.1.5.5) entries for the matching not returned for requesting EID 10.1.5.5) entries for the matching
EID-prefix of the requesting EID. When more than one EID-prefix is EID-prefix of the requesting EID. When more than one EID-prefix is
returned, all SHOULD use the same Time-to-Live value so they can all returned, all SHOULD use the same Time-to-Live value so they can all
time out at the same time. When a more specific EID-prefix is time out at the same time. When a more specific EID-prefix is
received later, its Time-to-Live value in the Map-Reply record can be received later, its Time-to-Live value in the Map-Reply record can be
stored even when other less specifics exist. When a a less specific stored even when other less specifics exist. When a a less specific
EID-prefix is received later, its map-cache expiration time should be EID-prefix is received later, its map-cache expiration time SHOULD be
set to the minimum expiration time of any more specific EID-prefix in set to the minimum expiration time of any more specific EID-prefix in
the map-cache. the map-cache.
Map-Replies SHOULD be sent for an EID-prefix no more often than once Map-Replies SHOULD be sent for an EID-prefix no more often than once
per second to the same requesting router. For scalability, it is per second to the same requesting router. For scalability, it is
expected that aggregation of EID addresses into EID-prefixes will expected that aggregation of EID addresses into EID-prefixes will
allow one Map-Reply to satisfy a mapping for the EID addresses in the allow one Map-Reply to satisfy a mapping for the EID addresses in the
prefix range thereby reducing the number of Map-Request messages. prefix range thereby reducing the number of Map-Request messages.
Map-Reply records can have an empty locator-set. This type of a Map- Map-Reply records can have an empty locator-set. This type of a Map-
skipping to change at page 34, line 39 skipping to change at page 36, line 18
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 When sending a Map-Reply message, the destination address is copied
from the source address of the Map-Request or Data-Probe message from the one of the ITR-RLOC fields from the Map-Request. The ETR
which is invoking the reply. The source address of the Map-Reply is can choose a locator address from one of the address families it
one of the local locator addresses listed in the locator-set of any supports. For Data-Probes, the destination address of the Map-Reply
mapping record in the message. The destination port of a Map-Reply is copied from the source address of the Data-Probe message which is
message is copied from the source port of the Map-Request or Data- invoking the reply. The source address of the Map-Reply is one of
Probe and the source port of the Map-Reply message is set to the the local locator addresses listed in the locator-set of any mapping
well-known UDP port 4342. record in the message and SHOULD be chosen to allow uRPF checks to
succeed in the upstream service provider. 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 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-reply on behalf of ETRs used. The first is to have Map-Servers proxy-map-reply on behalf of
so their registered EID-prefixes are the ones returned in Map- ETRs so their registered EID-prefixes are the ones returned in Map-
Replies. Since the interaction between an ETR and Map-Server is Replies. Since the interaction between an ETR and Map-Server is
secured with shared-keys, it is more difficult for an ETR to secured with shared-keys, it is more difficult for an ETR to
misbehave. The second solution is to have ITRs and PTRs cache EID- misbehave. The second solution is to have ITRs and PTRs cache EID-
prefixes with mask-lengths that are greater than or equal to a prefixes with mask-lengths that are greater than or equal to a
configured prefix length. This limits the damage to a specific width configured prefix length. This limits the damage to a specific width
of any EID-prefix advertised, but needs to be coordinated with the of any EID-prefix advertised, but needs to be coordinated with the
allocation of site prefixes. These solutions can be used allocation of site prefixes. These solutions can be used
independently or at the same time. independently or at the same time.
At the time of this writing, other approaches are being considered At the time of this writing, other approaches are being considered
skipping to change at page 36, line 22 skipping to change at page 37, line 33
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length | | Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Rsvd | Map-Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: Set to 1 by an ETR which sends a Map-Register message requesting P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map-
for the Map-Server to proxy Map-Reply. The Map-Server will send Register message requesting for the Map-Server to proxy Map-Reply.
non-authoritative Map-Replies on behalf of the ETR. Details on The Map-Server will send non-authoritative Map-Replies on behalf
this usage will be provided in a future version of this draft. of the ETR. Details on this usage will be provided in a future
version of this draft.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages.
Key ID: A configured ID to find the configured Message Key ID: A configured ID to find the configured Message
skipping to change at page 37, line 28 skipping to change at page 38, line 44
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. However, the record TTL field is not used and set Map-Reply section. However, the record TTL field is not used and set
to 0. to 0.
6.1.7. Encapsualted Control Message Format 6.1.7. Encapsulated 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
skipping to change at page 39, line 11 skipping to change at page 40, line 11
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. When Map-Requests are sent for RLOC-probing purposes (i.e study. When Map-Requests are sent for RLOC-probing purposes (i.e
the P-bit is set), they MUST not be sent inside Encapsulated the probe-bit is set), they MUST NOT be sent inside Encapsulated
Control Messages. 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.
skipping to change at page 40, line 10 skipping to change at page 41, line 10
send a Map-Request. For example, if the server-side ETR does not send a Map-Request. For example, if the server-side ETR does not
send Map-Requests, it gleans RLOCs from the client-side ITR, send Map-Requests, it gleans RLOCs from the client-side ITR,
giving the client-side ITR responsibility for bidirectional RLOC giving the client-side ITR responsibility for bidirectional RLOC
reachability and preferability. Server-side ETR gleaning of the reachability and preferability. Server-side ETR gleaning of the
client-side ITR RLOC is done by caching the inner header source client-side ITR RLOC is done by caching the inner header source
EID and the outer header source RLOC of received packets. The EID and the outer header source RLOC of received packets. The
client-side ITR controls how traffic is returned and can alternate client-side ITR controls how traffic is returned and can alternate
using an outer header source RLOC, which then can be added to the using an outer header source RLOC, which then can be added to the
list the server-side ETR uses to return traffic. Since no list the server-side ETR uses to return traffic. Since no
Priority or Weights are provided using this method, the server- Priority or Weights are provided using this method, the server-
side ETR must assume each client-side ITR RLOC uses the same best side ETR MUST assume each client-side ITR RLOC uses the same best
Priority with a Weight of zero. In addition, since EID-prefix Priority with a Weight of zero. In addition, since EID-prefix
encoding cannot be conveyed in data packets, the EID-to-RLOC cache encoding cannot be conveyed in data packets, the EID-to-RLOC cache
on tunnel routers can grow to be very large. on tunnel routers can grow to be very large.
o A "gleaned" map-cache entry, one learned from the source RLOC of a o A "gleaned" map-cache entry, one learned from the source RLOC of a
received encapsulated packet, is only stored and used for a few received encapsulated packet, is only stored and used for a few
seconds, pending verification. Verification is performed by seconds, pending verification. Verification is performed by
sending a Map-Request to the source EID (the inner header IP sending a Map-Request to the source EID (the inner header IP
source address) of the received encapsulated packet. A reply to source address) of the received encapsulated packet. A reply to
this "verifying Map-Request" is used to fully populate the map- this "verifying Map-Request" is used to fully populate the map-
skipping to change at page 43, line 6 skipping to change at page 44, line 6
The ITR can test the reachability of the unreachable Locator by The ITR can test the reachability of the unreachable Locator by
sending periodic Requests. Both Requests and Replies MUST be rate- sending periodic Requests. Both Requests and Replies MUST be rate-
limited. Locator reachability testing is never done with data limited. Locator reachability testing is never done with data
packets since that increases the risk of packet loss for end-to-end packets since that increases the risk of packet loss for end-to-end
sessions. sessions.
When an ETR decapsulates a packet, it knows that it is reachable from When an ETR decapsulates a packet, it knows that it is reachable from
the encapsulating ITR because that is how the packet arrived. In the encapsulating ITR because that is how the packet arrived. In
most cases, the ETR can also reach the ITR but cannot assume this to most cases, the ETR can also reach the ITR but cannot assume this to
be true due to the possibility of path asymmetry. In the presence of be true due to the possibility of path asymmetry. In the presence of
unidirectional traffic flow from an ITR to an ETR, the ITR should not unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT
use the lack of return traffic as an indication that the ETR is use the lack of return traffic as an indication that the ETR is
unreachable. Instead, it must use an alternate mechanisms to unreachable. Instead, it MUST use an alternate mechanisms to
determine reachability. determine reachability.
6.3.1. Echo Nonce Algorithm 6.3.1. Echo Nonce Algorithm
When there is bidirectional data flow between a pair of locators, a When data flows bidirectionally between locators from different
simple mechanism called "nonce echoing" can be used to determine sites, a simple mechanism called "nonce echoing" can be used to
reachability between an ITR and ETR. When an ITR wants to solicit a determine reachability between an ITR and ETR. When an ITR wants to
nonce echo, it sets the N and E bits and places a 24-bit nonce in the solicit a nonce echo, it sets the N and E bits and places a 24-bit
LISP header of the next encapsulated data packet. nonce in the LISP header of the next encapsulated data packet.
When this packet is received by the ETR, the encapsulated packet is When this packet is received by the ETR, the encapsulated packet is
forwarded as normal. When the ETR next sends a data packet to the forwarded as normal. When the ETR next sends a data packet to the
ITR, it includes the nonce received earlier with the N bit set and E ITR, it includes the nonce received earlier with the N bit set and E
bit cleared. The ITR sees this "echoed nonce" and knows the path to bit cleared. The ITR sees this "echoed nonce" and knows the path to
and from the ETR is up. and from the ETR is up.
The ITR will set the E-bit and N-bit for every packet it sends while The ITR will set the E-bit and N-bit for every packet it sends while
in echo-nonce-request state. The time the ITR waits to process the in echo-nonce-request state. The time the ITR waits to process the
echoed nonce before it determines the path is unreachable is variable echoed nonce before it determines the path is unreachable is variable
and a choice left for the implementation. and a choice left for the implementation.
If the ITR is receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does not see the
nonce echoed while being in echo-nonce-request state, then the path nonce echoed while being in echo-nonce-request state, then the path
to the ETR is unreachable. This decision may be overridden by other to the ETR is unreachable. This decision may be overridden by other
locator reachability algorithms. Once the ITR determines the path to locator reachability algorithms. Once the ITR determines the path to
the ETR is down it can switch to another locator for that EID-prefix. the ETR is down it can switch to another locator for that EID-prefix.
Note that "ITR" and "ETR" are relative terms here. Both devices must Note that "ITR" and "ETR" are relative terms here. Both devices MUST
be implementing both ITR and ETR functionality for the echo nonce be implementing both ITR and ETR functionality for the echo nonce
mechanism to operate. mechanism to operate.
The ITR and ETR may both go into echo-nonce-request state at the same The ITR and ETR may both go into echo-nonce-request state at the same
time. The number of packets sent or the time during which echo nonce time. The number of packets sent or the time during which echo nonce
requests are sent is an implementation specific setting. However, requests are sent is an implementation specific setting. However,
when an ITR is in echo-nonce-request state, it can echo the ETR's when an ITR is in echo-nonce-request state, it can echo the ETR's
nonce in the next set of packets that it encapsulates and then nonce in the next set of packets that it encapsulates and then
subsequently, continue sending echo-nonce-request packets. subsequently, continue sending echo-nonce-request packets.
This mechanism does not completely solve the forward path This mechanism does not completely solve the forward path
reachability problem as traffic may be unidirectional. That is, the reachability problem as traffic may be unidirectional. That is, the
ETR receiving traffic at a site may not may not be the same device as ETR receiving traffic at a site may not be the same device as an ITR
an ITR which transmits traffic from that site or the site to site which transmits traffic from that site or the site to site traffic is
traffic is unidirectional so there is no ITR returning traffic. unidirectional so there is no ITR returning traffic.
The echo-nonce algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if one side sets the
E-bit and the other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for echo-noncing, then the
echoing of the nonce does not occur and the requesting side may echoing of the nonce does not occur and the requesting side may
regard the locator unreachable erroneously. An ITR should only set regard the locator unreachable erroneously. An ITR SHOULD only set
the E-bit in a encapsulated data packet when it knows the ETR is the E-bit in a encapsulated data packet when it knows the ETR is
enabled for echo-noncing. This is conveyed by the E-bit in the Map- enabled for echo-noncing. This is conveyed by the E-bit in the Map-
Reply message. Reply message.
Note that other locator reachability mechanisms are being researched Note that other locator reachability mechanisms are being researched
and can be used to compliment or even override the Echo Nonce and can be used to compliment or even override the Echo Nonce
Algorithm. See next section for an example of control-plane probing. Algorithm. See next section for an example of control-plane probing.
6.3.2. RLOC Probing Algorithm 6.3.2. RLOC Probing Algorithm
RLOC Probing is a method that an ITR or PTR can use to determine the RLOC Probing is a method that an ITR or PTR can use to determine the
reachability status of one or more locators that it has cached in a reachability status of one or more locators that it has cached in a
map-cache entry. The P-bit (Probe Bit) of the Map-Request and Map- map-cache entry. The probe-bit of the Map-Request and Map-Reply
Reply messages are used for RLOC Probing. messages are used for RLOC Probing.
RLOC probing is done in the control-plane on a timer basis where an RLOC probing is done in the control-plane on a timer basis where an
ITR or PTR will originate a Map-Request destined to a locator address ITR or PTR will originate a Map-Request destined to a locator address
from one of its own locator addresses. A Map-Request used as an from one of its own locator addresses. A Map-Request used as an
RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the
ALT like one would when soliciting mapping data. The EID record ALT like one would when soliciting mapping data. The EID record
encoded in the Map-Request is the EID-prefix of the map-cache entry encoded in the Map-Request is the EID-prefix of the map-cache entry
cached by the ITR or PTR. The ITR or PTR may include a mapping data cached by the ITR or PTR. The ITR or PTR may include a mapping data
record for its own database mapping information. record for its own database mapping information.
When an ETR receives a Map-Request message with the P-bit set, it When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the P-bit set. The source address of the returns a Map-Reply with the probe-bit set. The source address of
Map-Reply is set from the destination address of the Map-Request and the Map-Reply is set from the destination address of the Map-Request
the destination address of the Map-Reply is set from the source and the destination address of the Map-Reply is set from the source
address of the Map-Request. The Map-Reply should contain mapping address of the Map-Request. The Map-Reply SHOULD contain mapping
data for the EID-prefix contained in the Map-Request. This provides data for the EID-prefix contained in the Map-Request. This provides
the opportunity for the ITR or PTR, which sent the RLOC-probe to get the opportunity for the ITR or PTR, which sent the RLOC-probe to get
mapping updates if there were changes to the ETR's database mapping mapping updates if there were changes to the ETR's database mapping
entries. entries.
There are advantages and disadvantages of RLOC Probing. The greatest There are advantages and disadvantages of RLOC Probing. The greatest
benefit of RLOC Probing is that it can handle many failure scenarios benefit of RLOC Probing is that it can handle many failure scenarios
allowing the ITR to determine when the path to a specific locator is allowing the ITR to determine when the path to a specific locator is
reachable or has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a robust
mechanism for switching to using another locator from the cached mechanism for switching to using another locator from the cached
locator. RLOC Probing can also provide RTT estimates between a pair locator. RLOC Probing can also provide rough RTT estimates between a
of locators which can be useful for network management purposes as pair of locators which can be useful for network management purposes
well as for selecting low delay paths. The major disadvantage of as well as for selecting low delay paths. The major disadvantage of
RLOC Probing is in the number of control messages required and the RLOC Probing is in the number of control messages required and the
amount of bandwidth used to obtain those benefits, especially if the amount of bandwidth used to obtain those benefits, especially if the
requirement for failure detection times are very small. requirement for failure detection times are very small.
Continued research and testing will attempt to characterize the Continued research and testing will attempt to characterize the
tradeoffs of failure detection times versus message overhead. tradeoffs of failure detection times versus message overhead.
6.4. Routing Locator Hashing 6.4. Routing Locator Hashing
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
skipping to change at page 46, line 41 skipping to change at page 47, line 41
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
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 three approaches for locator-set compaction, one
operational and the other a protocol mechanism. The operational operational and two protocol mechanisms. The operational approach
approach uses a clock sweep method. The protocol approach uses the uses a clock sweep method. The protocol approaches use the concept
concept of Solicit-Map-Requests. of Solicit-Map-Requests and Map-Versioning.
6.5.1. Clock Sweep 6.5.1. Clock Sweep
The clock sweep approach uses planning in advance and the use of The clock sweep approach uses planning in advance and the use of
count-down TTLs to time out mappings that have already been cached. count-down TTLs to time out mappings that have already been cached.
The default setting for an EID-to-RLOC mapping TTL is 24 hours. So The default setting for an EID-to-RLOC mapping TTL is 24 hours. So
there is a 24 hour window to time out old mappings. The following there is a 24 hour window to time out old mappings. The following
clock sweep procedure is used: clock sweep procedure is used:
1. 24 hours before a mapping change is to take effect, a network 1. 24 hours before a mapping change is to take effect, a network
skipping to change at page 47, line 40 skipping to change at page 48, line 40
Since the xTRs don't keep track of remote ITRs that have cached their Since the xTRs don't keep track of remote ITRs that have cached their
mappings, they can not tell exactly who needs the new mapping mappings, they can not tell exactly who needs the new mapping
entries. So an xTR will solicit Map-Requests from sites it is entries. So an xTR will solicit Map-Requests from sites it is
currently sending encapsulated data to, and only from those sites. currently sending encapsulated data to, and only from those sites.
The xTRs can locally decide the algorithm for how often and to how The xTRs can locally decide the algorithm for how often and to how
many sites it sends SMR messages. many sites it sends SMR messages.
An SMR message is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request message. An ITR
or PTR will send a Map-Request when they receive an SMR message. or PTR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder must rate-limited Both the SMR sender and the Map-Request responder MUST rate-limited
these messages. these messages.
The following procedure shows how a SMR exchange occurs when a site The following procedure shows how a SMR exchange occurs when a site
is doing locator-set compaction for an EID-to-RLOC mapping: is doing locator-set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site 1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each locator begin to send Map-Requests with the SMR bit set for each locator
in each map-cache entry the ETR caches. in each map-cache entry the ETR caches.
2. A remote xTR which receives the SMR message will schedule sending 2. A remote xTR which receives the SMR message will schedule sending
a Map-Request message to the source locator address of the SMR a Map-Request message to the source locator address of the SMR
message. A newly allocated random nonce is selected and the EID- message. A newly allocated random nonce is selected and the EID-
prefix uses is the one copied from the SMR message. prefix used is the one copied from the SMR message.
3. The remote xTR retransmits the Map-Request slowly until it gets a 3. The remote xTR MUST rate-limit the Map-Request until it gets a
Map-Reply while continuing to use the cached mapping. Map-Reply while continuing to use the cached mapping.
4. The ETRs at the site with the changed mapping will reply to the 4. The ETRs at the site with the changed mapping will reply to the
Map-Request with a Map-Reply message provided the Map-Request Map-Request with a Map-Reply message provided the Map-Request
nonce matches the nonce from the SMR. The Map-Reply messages nonce matches the nonce from the SMR. The Map-Reply messages
SHOULD be rate limited. This is important to avoid Map-Reply SHOULD be rate limited. This is important to avoid Map-Reply
implosion. implosion.
5. The ETRs, at the site with the changed mapping, records the fact 5. The ETRs, at the site with the changed mapping, record the fact
that the site that sent the Map-Request has received the new that the site that sent the Map-Request has received the new
mapping data in the mapping cache entry for the remote site so mapping data in the mapping cache entry for the remote site so
the loc-status-bits are reflective of the new mapping for packets the loc-status-bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops sending SMR
messages. messages.
For security reasons an ITR MUST NOT process unsolicited Map-Replies. For security reasons an ITR MUST NOT process unsolicited Map-Replies.
The nonce MUST be carried from SMR packet, into the resultant Map- The nonce MUST be carried from SMR packet, into the resultant Map-
Request, and then into Map-Reply to reduce spoofing attacks. Request, and then into Map-Reply to reduce spoofing attacks.
To avoid map-cache entry corruption by a third-party, a sender of an To avoid map-cache entry corruption by a third-party, a sender of an
SMR-based Map-Request must be verified. If an ITR receives an SMR- SMR-based Map-Request MUST be verified. If an ITR receives an SMR-
based Map-Request and the source is not in the locator-set for the based Map-Request and the source is not in the locator-set for the
stored map-cache entry, then the responding Map-Request MUST be sent stored map-cache entry, then the responding Map-Request MUST be sent
with an EID destination to the mapping database system. Since the with an EID destination to the mapping database system. Since the
mapping database system is more secure to reach an authoritative ETR, mapping database system is more secure to reach an authoritative ETR,
it will deliver the Map-Request to the authoritative source of the it will deliver the Map-Request to the authoritative source of the
mapping data. mapping data.
6.5.3. Database Map Versioning
When there is unidirectional packet flow between an ITR and ETR, and
the EID-to-RLOC mappings change on the ETR, it needs to inform the
ITR so encapsulation can stop to a removed locator and start to a new
locator in the locator-set.
An ETR, when it sends Map-Reply messages, conveys its own Map-Version
number. This is known as the Destination Map-Version Number. ITRs
include the Destination Map-Version Number in packets they
encapsulate to the site. When an ETR decapsulates a packet and
detects the Destination Map-Version Number is less than the current
version for its mapping, the SMR procedure described in Section 6.5.2
occurs.
An ITR, when it encapsulates packets to ETRs, can convey its own Map-
Version number. This is known as the Source Map-Version Number.
When an ETR decapsulates a packet and detects the Source Map-Version
Number is greater than the last Map-Version Number sent in a Map-
Reply from the ITR's site, the ETR will send a Map-Request to one of
the ETRs for the source site.
A Map-Version Number is used as a sequence number per EID-prefix. So
values that are greater, are considered to be more recent. A value
of 0 for the Source Map-Version Number or the Destination Map-Version
Number conveys no versioning information and an xTR does no
comparison with previously received Map-Version Numbers.
A Map-Version Number can be included in Map-Register messages as
well. This is a good way for the Map-Server can assure that all ETRs
for a site registering to it will be Map-Version number synchronized.
See [VERSIONING] for a more detailed analysis and description of
Database Map Versioning.
7. Router Performance Considerations 7. Router Performance Considerations
LISP is designed to be very hardware-based forwarding friendly. By LISP is designed to be very hardware-based forwarding friendly. By
doing tunnel header prepending [RFC1955] and stripping instead of re- doing tunnel header prepending [RFC1955] and stripping instead of re-
writing addresses, existing hardware can support the forwarding model writing addresses, existing hardware can support the forwarding model
with little or no modification. Where modifications are required, with little or no modification. Where modifications are required,
they should be limited to re-programming existing hardware rather they should be limited to re-programming existing hardware rather
than requiring expensive design changes to hard-coded algorithms in than requiring expensive design changes to hard-coded algorithms in
silicon. silicon.
skipping to change at page 53, line 5 skipping to change at page 54, line 25
site. site.
An obvious disadvantage is that the end site has no control over An obvious disadvantage is that the end site has no control over
where its packets flow or the RLOCs used. where its packets flow or the RLOCs used.
As mentioned in earlier sections a combination of these scenarios is As mentioned in earlier sections a combination of these scenarios is
possible at the expense of extra packet header overhead, if both site possible at the expense of extra packet header overhead, if both site
and provider want control, then recursive or re-encapsulating tunnels and provider want control, then recursive or re-encapsulating tunnels
are used. are used.
8.4. LISP Functionality with Conventional NATs
LISP routers can be deployed behind Network Address Translator (NAT)
devices to provide the same set of packet services hosts have today
when they are addressed out of private address space.
It is important to note that a locator address in any LISP control
message MUST be a globally routable address and therefore SHOULD NOT
contain [RFC1918] addresses. If a LISP router is configured with
private addresses, they MUST be used only in the outer IP header so
the NAT device can translate properly. Otherwise, EID addresses MUST
be translated before encapsulation is performed. Both NAT
translation and LISP encapsulation functions could be co-located in
the same device.
More details on LISP address translation can be found in [INTERWORK].
9. Traceroute Considerations 9. Traceroute Considerations
When a source host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a traceroute to a
destination host in another LISP site, it is highly desirable for it destination host in another LISP site, it is highly desirable for it
to see the entire path. Since packets are encapsulated from ITR to to see the entire path. Since packets are encapsulated from ITR to
ETR, the hop across the tunnel could be viewed as a single hop. ETR, the hop across the tunnel could be viewed as a single hop.
However, LISP traceroute will provide the entire path so the user can However, LISP traceroute will provide the entire path so the user can
see 3 distinct segments of the path from a source LISP host to a see 3 distinct segments of the path from a source LISP host to a
destination LISP host: destination LISP host:
skipping to change at page 53, line 36 skipping to change at page 55, line 36
For segment 1 of the path, ICMP Time Exceeded messages are returned For segment 1 of the path, ICMP Time Exceeded messages are returned
in the normal matter as they are today. The ITR performs a TTL in the normal matter as they are today. The ITR performs a TTL
decrement and test for 0 before encapsulating. So the ITR hop is decrement and test for 0 before encapsulating. So the ITR hop is
seen by the traceroute source has an EID address (the address of seen by the traceroute source has an EID address (the address of
site-facing interface). site-facing interface).
For segment 2 of the path, ICMP Time Exceeded messages are returned For segment 2 of the path, ICMP Time Exceeded messages are returned
to the ITR because the TTL decrement to 0 is done on the outer to the ITR because the TTL decrement to 0 is done on the outer
header, so the destination of the ICMP messages are to the ITR RLOC header, so the destination of the ICMP messages are to the ITR RLOC
address, the source source RLOC address of the encapsulated address, the source RLOC address of the encapsulated traceroute
traceroute packet. The ITR looks inside of the ICMP payload to packet. The ITR looks inside of the ICMP payload to inspect the
inspect the traceroute source so it can return the ICMP message to traceroute source so it can return the ICMP message to the address of
the address of the traceroute client as well as retaining the core the traceroute client as well as retaining the core router IP address
router IP address in the ICMP message. This is so the traceroute in the ICMP message. This is so the traceroute client can display
client can display the core router address (the RLOC address) in the the core router address (the RLOC address) in the traceroute output.
traceroute output. The ETR returns its RLOC address and responds to The ETR returns its RLOC address and responds to the TTL decrement to
the TTL decrement to 0 like the previous core routers did. 0 like the previous core routers did.
For segment 3, the next-hop router downstream from the ETR will be For segment 3, the next-hop router downstream from the ETR will be
decrementing the TTL for the packet that was encapsulated, sent into decrementing the TTL for the packet that was encapsulated, sent into
the core, decapsulated by the ETR, and forwarded because it isn't the the core, decapsulated by the ETR, and forwarded because it isn't the
final destination. If the TTL is decremented to 0, any router on the final destination. If the TTL is decremented to 0, any router on the
path to the destination of the traceroute, including the next-hop path to the destination of the traceroute, including the next-hop
router or destination, will send an ICMP Time Exceeded message to the router or destination, will send an ICMP Time Exceeded message to the
source EID of the traceroute client. The ICMP message will be source EID of the traceroute client. The ICMP message will be
encapsulated by the local ITR and sent back to the ETR in the encapsulated by the local ITR and sent back to the ETR in the
originated traceroute source site, where the packet will be delivered originated traceroute source site, where the packet will be delivered
skipping to change at page 54, line 42 skipping to change at page 56, line 42
16-bit number as the UDP source port in the encapsulating header. 16-bit number as the UDP source port in the encapsulating header.
When the ICMP Time Exceeded message is returned to the ITR, the UDP When the ICMP Time Exceeded message is returned to the ITR, the UDP
header of the encapsulating header is present in the ICMP payload header of the encapsulating header is present in the ICMP payload
thereby allowing the ITR to find the cached headers for the thereby allowing the ITR to find the cached headers for the
traceroute source. The ITR puts the cached headers in the payload traceroute source. The ITR puts the cached headers in the payload
and sends the ICMP Time Exceeded message to the traceroute source and sends the ICMP Time Exceeded message to the traceroute source
retaining the source address of the original ICMP Time Exceeded retaining the source address of the original ICMP Time Exceeded
message (a core router or the ETR of the site of the traceroute message (a core router or the ETR of the site of the traceroute
destination). destination).
The signature of a traceroute packet comes in two forms. The first
form is encoded as a UDP message where the destination port is
inspected for a range of values. The second form is encoded as an
ICMP message where the IP identification field is inspected for a
well-known value.
9.3. Traceroute using Mixed Locators 9.3. Traceroute using Mixed Locators
When either an IPv4 traceroute or IPv6 traceroute is originated and When either an IPv4 traceroute or IPv6 traceroute is originated and
the ITR encapsulates it in the other address family header, you the ITR encapsulates it in the other address family header, you
cannot get all 3 segments of the traceroute. Segment 2 of the cannot get all 3 segments of the traceroute. Segment 2 of the
traceroute can not be conveyed to the traceroute source since it is traceroute can not be conveyed to the traceroute source since it is
expecting addresses from intermediate hops in the same address format expecting addresses from intermediate hops in the same address format
for the type of traceroute it originated. Therefore, in this case, for the type of traceroute it originated. Therefore, in this case,
segment 2 will make the tunnel look like one hop. All the ITR has to segment 2 will make the tunnel look like one hop. All the ITR has to
do to make this work is to not copy the inner TTL to the outer, do to make this work is to not copy the inner TTL to the outer,
skipping to change at page 57, line 49 skipping to change at page 59, line 49
location. location.
When both endpoints are mobile the number of potential mapping When both endpoints are mobile the number of potential mapping
lookups increases accordingly. lookups increases accordingly.
As a mobile node moves there are not only mobility state changes in As a mobile node moves there are not only mobility state changes in
the mobile node, correspondent node, and home agent, but also state the mobile node, correspondent node, and home agent, but also state
changes in the ITRs and ETRs for at least some EID-prefixes. changes in the ITRs and ETRs for at least some EID-prefixes.
The goal is to support rapid adaptation, with little delay or packet The goal is to support rapid adaptation, with little delay or packet
loss for the entire system. Heuristics can be added to LISP to loss for the entire system. Also IP mobility can be modified to
reduce the number of mapping changes required and to reduce the delay require fewer mapping changes. In order to increase overall system
per mapping change. Also IP mobility can be modified to require
fewer mapping changes. In order to increase overall system
performance, there may be a need to reduce the optimization of one performance, there may be a need to reduce the optimization of one
area in order to place fewer demands on another. area in order to place fewer demands on another.
In LISP, one possibility is to "glean" information. When a packet In LISP, one possibility is to "glean" information. When a packet
arrives, the ETR could examine the EID-RLOC mapping and use that arrives, the ETR could examine the EID-RLOC mapping and use that
mapping for all outgoing traffic to that EID. It can do this after mapping for all outgoing traffic to that EID. It can do this after
performing a route-returnability check, to ensure that the new performing a route-returnability check, to ensure that the new
network location does have a internal route to that endpoint. network location does have a internal route to that endpoint.
However, this does not cover the case where an ITR (the node assigned However, this does not cover the case where an ITR (the node assigned
the RLOC) at the mobile-node location has been compromised. the RLOC) at the mobile-node location has been compromised.
skipping to change at page 60, line 39 skipping to change at page 62, line 39
Therefore, an EID-to-RLOC mapping does not need to be performed by an Therefore, an EID-to-RLOC mapping does not need to be performed by an
ITR when a received data packet is a multicast data packet or when ITR when a received data packet is a multicast data packet or when
processing a source-specific Join (either by IGMPv3 or PIM). But the processing a source-specific Join (either by IGMPv3 or PIM). But the
source Routing Locator is decided by the multicast routing protocol source Routing Locator is decided by the multicast routing protocol
in a receiver site. That is, an EID to Routing Locator translation in a receiver site. That is, an EID to Routing Locator translation
is done at control-time. is done at control-time.
Another approach is to have the ITR not encapsulate a multicast Another approach is to have the ITR not encapsulate a multicast
packet and allow the the host built packet to flow into the core even packet and allow the the host built packet to flow into the core even
if the source address is allocated out of the EID namespace. If the if the source address is allocated out of the EID namespace. If the
RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
can RPF to the ITR (the Locator address which is injected into core routers can RPF to the ITR (the Locator address which is injected
routing) rather than the host source address (the EID address which into core routing) rather than the host source address (the EID
is not injected into core routing). address which is not injected into core routing).
To avoid any EID-based multicast state in the network core, the first To avoid any EID-based multicast state in the network core, the first
approach is chosen for LISP-Multicast. Details for LISP-Multicast approach is chosen for LISP-Multicast. Details for LISP-Multicast
and Interworking with non-LISP sites is described in specification and Interworking with non-LISP sites is described in specification
[MLISP]. [MLISP].
12. Security Considerations 12. Security Considerations
It is believed that most of the security mechanisms will be part of It is believed that most of the security mechanisms will be part of
the mapping database service when using control plane procedures for the mapping database service when using control plane procedures for
skipping to change at page 62, line 5 skipping to change at page 64, line 5
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.
13. Prototype Plans and Status 13. IANA Considerations
This specification has already allocated UDP port numbers 4341 and
4342 assigned from the IANA registry.
14. Prototype Plans and Status
The operator community has requested that the IETF take a practical The operator community has requested that the IETF take a practical
approach to solving the scaling problems associated with global approach to solving the scaling problems associated with global
routing state growth. This document offers a simple solution which routing state growth. This document offers a simple solution which
is intended for use in a pilot program to gain experience in working is intended for use in a pilot program to gain experience in working
on this problem. on this problem.
The authors hope that publishing this specification will allow the The authors hope that publishing this specification will allow the
rapid implementation of multiple vendor prototypes and deployment on rapid implementation of multiple vendor prototypes and deployment on
a small scale. Doing this will help the community: a small scale. Doing this will help the community:
skipping to change at page 62, line 38 skipping to change at page 65, line 38
global routing system for this purpose. global routing system for this purpose.
o Experiment with mobility to determine if both acceptable o Experiment with mobility to determine if both acceptable
convergence and session continuity properties can be scalably convergence and session continuity properties can be scalably
implemented to support both individual device roaming and site implemented to support both individual device roaming and site
service provider changes. service provider changes.
Here is a rough set of milestones: Here is a rough set of milestones:
1. Interoperable implementations have been available since the 1. Interoperable implementations have been available since the
beginning of 2009. We are trying to converge on a packet format beginning of 2009.
so implementations can converge on the -04 and later drafts.
2. Continue pilot deployment using LISP-ALT as the database mapping 2. Continue pilot deployment using LISP-ALT as the database mapping
mechanism. mechanism.
3. Continue prototyping and studying other database lookup schemes, 3. Continue prototyping and studying other database lookup schemes,
be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.
4. Implement the LISP Multicast draft [MLISP]. 4. Implement the LISP Multicast draft [MLISP].
5. Implement the LISP Mobile Node draft [LISP-MN]. 5. Implement the LISP Mobile Node draft [LISP-MN].
skipping to change at page 63, line 44 skipping to change at page 66, line 44
1. cisco NX-OS 1. cisco NX-OS
2. OpenLISP 2. OpenLISP
3. LISP-Click 3. LISP-Click
4. ZLisp 4. ZLisp
5. cisco IOS 5. cisco IOS
6. Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and 6. Dave Meyer, Vince Fuller, Darrel Lewis, Gregg Schudel, Andrew
Andrew Partan continue to test all the features described above Partan and the rest of the lisp-beta team continue to test all
on a dual-stack infrastructure. the features described above on a dual-stack infrastructure.
7. 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.
8. 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.
9. An public domain implementation of LISP is underway. See 9. An public domain implementation of LISP is available. See
[OPENLISP] for details. [OPENLISP] for details.
10. 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.
11. A cisco IOS implementation is underway which currently supports 11. A cisco IOS implementation is available which currently supports
IPv4 encapsulation and decapsulation features. IPv4 and IPv6 encapsulation and decapsulation features.
12. 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.
13. 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.
skipping to change at page 64, line 45 skipping to change at page 67, line 45
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.
15. 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.
16. The LISP pilot network is in its 3rd generation. Current
experiments are being performed to test EID-prefix aggregation
at multiple service boundaries as well as deploying models for
the existence of multiple Mapping Service Providers (MSPs).
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 15. References
14.1. Normative References 15.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1498] Saltzer, J., "On the Naming and Binding of Network [RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993. Destinations", RFC 1498, August 1993.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and [RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
skipping to change at page 66, line 12 skipping to change at page 69, line 15
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006. (SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 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.
14.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/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-02.txt (work in progress), draft-ietf-lisp-alt-04.txt (work in progress), April 2010.
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 67, line 9 skipping to change at page 70, line 21
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-01.txt (work in progress), draft-ietf-lisp-interworking-01.txt (work in progress),
January 2010. March 2010.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-farinacci-lisp-lcaf-01.txt (work in
progress), April 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-ietf-lisp-lig-00.txt (work in progress), April 2010.
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,
"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.
[LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-00.txt (work Mobility Architecture", draft-meyer-lisp-mn-00.txt (work
in progress), July 2009. in progress), July 2009.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-03.txt (work in progress), draft-ietf-lisp-ms-05.txt (work in progress), April 2010.
September 2009.
[LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP1) [Routable ID "Locator/ID Separation Protocol (LISP1) [Routable ID
Version]", Version]",
Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
October 2006. October 2006.
[LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP2) [DNS-based "Locator/ID Separation Protocol (LISP2) [DNS-based
Version]", Version]",
skipping to change at page 68, line 8 skipping to change at page 71, line 22
February 2008. February 2008.
[LOC-ID-ARCH] [LOC-ID-ARCH]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Locator/ID Separation",
draft-meyer-loc-id-implications-01.txt (work in progress), draft-meyer-loc-id-implications-01.txt (work in progress),
Januaryr 2009. Januaryr 2009.
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-02.txt (work in progress), draft-ietf-lisp-multicast-03.txt (work in progress),
September 2009. April 2010.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-04.txt (work in progress), draft-lear-lisp-nerd-08.txt (work in progress),
April 2008. March 2010.
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
Report", draft-iannone-openlisp-implementation-01.txt Report", draft-iannone-openlisp-implementation-01.txt
(work in progress), July 2008. (work in progress), July 2008.
[RADIR] Narten, T., "Routing and Addressing Problem Statement", [RADIR] Narten, T., "Routing and Addressing Problem Statement",
draft-narten-radir-problem-statement-00.txt (work in draft-narten-radir-problem-statement-00.txt (work in
progress), July 2007. progress), July 2007.
[RFC3344bis] [RFC3344bis]
Perkins, C., "IP Mobility Support for IPv4, revised", Perkins, C., "IP Mobility Support for IPv4, revised",
draft-ietf-mip4-rfc3344bis-05 (work in progress), draft-ietf-mip4-rfc3344bis-05 (work in progress),
July 2007. July 2007.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector
TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress),
January 2009.
[RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
for Routing Protocol Meta-data Dissemination", for Routing Protocol Meta-data Dissemination",
draft-handley-p2ppush-unpublished-2007726.txt (work in draft-handley-p2ppush-unpublished-2007726.txt (work in
progress), July 2007. progress), July 2007.
[SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim [VERSIONING]
protocol", draft-ietf-shim6-proto-06.txt (work in Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
progress), October 2006. Versioning", draft-iannone-lisp-mapping-versioning-01.txt
(work in progress), March 2010.
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed review of the LISP of location and identity, as well as detailed review of the LISP
skipping to change at page 69, line 30 skipping to change at page 73, line 30
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, Jari Arkko, Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko,
Gregg Schudel, Srinivas Subramanian, Amit Jain, and Xu Xiaohu. Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra
Trivedi, Yakov Rekhter, John Scudder, John Drake, and Dimitri
Papadimitriou.
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-06.txt B.1. Changes to draft-ietf-lisp-07.txt
o Posted April 2010.
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
8-bits (from 32-bits).
o Added V-bit to the data header so the 24-bit nonce field can also
be used for source and destination version numbers.
o Added Map-Version 12-bit value to the EID-record to be used in all
of Map-Request, Map-Reply, and Map-Register messages.
o Added multiple ITR-RLOC fields to the Map-Request packet so an ETR
can decide what address to select for the destination of a Map-
Reply.
o Added L-bit (Local RLOC bit) and p-bit (Probe-Reply RLOC bit) to
the Locator-Set record of an EID-record for a Map-Reply message.
The L-bit indicates which RLOCs in the locator-set are local to
the sender of the message. The P-bit indicates which RLOC is the
source of a RLOC-probe Reply (Map-Reply) message.
o Add reference to the LISP Canonical Address Format [LCAF] draft.
o Made editorial and clarification changes based on comments from
Dhirendra Trivedi.
o Added wordsmithing comments from Joel Halpern on DF=1 setting.
o Add John Zwiebel clarification to Echo Nonce Algorithm section
6.3.1.
o Add John Zwiebel comment about expanding on proxy-map-reply bit
for Map-Register messages.
o Add NAT section per Ron Bonica comments.
o Fix IDnits issues per Ron Bonica.
o Added section on Virtualization and Segmentation to explain the
use if the Instance ID field in the data header.
o There are too many P-bits, keep their scope to the packet format
description and refer to them by name every where else in the
spec.
o Scanned all occurrences of "should", "should not", "must" and
"must not" and uppercased them.
o John Zwiebel offered text for section 4.1 to modernize the
example. Thanks Z!
o Make it more clear in the definition of "EID-to-RLOC Database"
that all ETRs need to have the same database mapping. This
reflects a comment from John Scudder.
o Add a definition "Route-returnability" to the Definition of Terms
section.
o In section 9.2, add text to describe what the signature of
traceroute packets can look like.
o Removed references to Data Probe for introductory example. Data-
probes are still part of the LISP design but not encouraged.
o Added the definition for "LISP site" to the Definition of Terms"
section.
B.2. 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 rflags 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.
o Add definitions for PITR and PETR. o Add definitions for PITR and PETR.
o Indicate an AFI value of 0 is an unspecified address. 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 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 to 0 by the sender. This change makes this spec consistent with
skipping to change at page 71, line 16 skipping to change at page 76, line 37
These type of Map-Requests are used as RLOC-probes and are sent These type of Map-Requests are used as RLOC-probes and are sent
directly to locator addresses in the underlying network. directly to locator addresses in the underlying network.
o Add text in section 6.1.5 about returning all EID-prefixes in a o Add text in section 6.1.5 about returning all EID-prefixes in a
Map-Reply sent by an ETR when there are overlapping EID-prefixes Map-Reply sent by an ETR when there are overlapping EID-prefixes
configure. configure.
o Add text in a new subsection of section 6.1.5 about dealing with o Add text in a new subsection of section 6.1.5 about dealing with
Map-Replies with coarse EID-prefixes. Map-Replies with coarse EID-prefixes.
B.2. Changes to draft-ietf-lisp-05.txt B.3. 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 71, line 44 skipping to change at page 77, line 16
o The LISP-CONS authors thought that the Type definitions for CONS o The LISP-CONS authors thought that the Type definitions for CONS
should be removed from this specification. should be removed from this specification.
o Removed nonce from Map-Register message, it wasn't used so no need o Removed nonce from Map-Register message, it wasn't used so no need
for it. for it.
o Clarify what to do for unspecified Action bits for negative Map- o Clarify what to do for unspecified Action bits for negative Map-
Replies. Since No Action is a drop, make value 0 Drop. Replies. Since No Action is a drop, make value 0 Drop.
B.3. Changes to draft-ietf-lisp-04.txt B.4. 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 73, line 35 skipping to change at page 79, line 10
o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Reference IPsec RFC 4302. Comment from Sam and Brian Weis.
o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
noncing. Comment by Pedro and Dino. noncing. Comment by Pedro and Dino.
o Jesper made a comment to loosen the language about requiring the o Jesper made a comment to loosen the language about requiring the
copy of inner TTL to outer TTL since the text to get mixed-AF copy of inner TTL to outer TTL since the text to get mixed-AF
traceroute to work would violate the "MUST" clause. Changed from traceroute to work would violate the "MUST" clause. Changed from
MUST to SHOULD in section 5.3. MUST to SHOULD in section 5.3.
B.4. Changes to draft-ietf-lisp-03.txt B.5. 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.5. Changes to draft-ietf-lisp-02.txt B.6. 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.6. Changes to draft-ietf-lisp-01.txt B.7. 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.7. Changes to draft-ietf-lisp-00.txt B.8. 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. 118 change blocks. 
256 lines changed or deleted 540 lines changed or added

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