draft-ietf-lisp-07.txt   draft-ietf-lisp-08.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: October 27, 2010 D. Lewis Expires: February 14, 2011 D. Lewis
cisco Systems cisco Systems
April 25, 2010 August 13, 2010
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-07 draft-ietf-lisp-08
Abstract Abstract
This draft describes a simple, incremental, network-based protocol to This draft describes a network-based protocol that enables separation
implement separation of Internet addresses into Endpoint Identifiers of IP addresses into two new numbering spaces: Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). This mechanism requires no (EIDs) and Routing Locators (RLOCs). No changes are required to
changes to host stacks and no major changes to existing database either host protocol stacks or to the "core" of the Internet
infrastructures. The proposed protocol can be implemented in a infrastructure. LISP can be incrementally deployed, without a "flag
relatively small number of routers. day", and offers traffic engineering, multi-homing, and mobility
benefits even to early adopters, when there are relatively few LISP-
capable sites.
This proposal was stimulated by the problem statement effort at the Design and development of LISP was largely motivated by the problem
Amsterdam IAB Routing and Addressing Workshop (RAWS), which took statement produced by the October, 2006 IAB Routing and Addressing
place in October 2006. Workshop.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 27, 2010. This Internet-Draft will expire on February 14, 2011.
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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 21 skipping to change at page 2, line 24
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
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. LISP Encapsulation 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 . . . . . . . . . . . . . 17
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 22 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 23 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24
5.5. Using Virtualization and Segmentation with LISP . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 25 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 25 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 27 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 27 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 29 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 30
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 31 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 34 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 35
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 37 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38
6.1.7. Encapsulated Control Message Format . . . . . . . . . 38 6.1.7. Encapsulated Control Message Format . . . . . . . . . 39
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 40 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 41
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 41 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 42
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 44 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 45
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 45 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 46
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 46 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 47
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 47 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 47
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 47 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 48
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 48 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 49
6.5.3. Database Map Versioning . . . . . . . . . . . . . . . 49 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 49
7. Router Performance Considerations . . . . . . . . . . . . . . 51 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 51
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 52 7. Router Performance Considerations . . . . . . . . . . . . . . 52
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 53 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 53
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 53 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 54
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 54 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 54
8.4. LISP Functionality with Conventional NATs . . . . . . . . 54 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 55
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 55 8.4. LISP Functionality with Conventional NATs . . . . . . . . 55
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 56 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 56
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 56 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 57
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 56 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 57
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 58 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 57
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 58 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 59
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 58 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 59
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 58 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 59
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 60 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 59
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 60 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 61
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 62 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 61
12. Security Considerations . . . . . . . . . . . . . . . . . . . 63 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 63
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 64
14. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 65 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
15.1. Normative References . . . . . . . . . . . . . . . . . . . 68 14.1. Normative References . . . . . . . . . . . . . . . . . . . 66
15.2. Informative References . . . . . . . . . . . . . . . . . . 69 14.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 73 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 70
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 74 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 71
B.1. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 74 B.1. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 71
B.2. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 75 B.2. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 72
B.3. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 76 B.3. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 74
B.4. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 77 B.4. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 75
B.5. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 79 B.5. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 76
B.6. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 79 B.6. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 77
B.7. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 79 B.7. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 78
B.8. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 80 B.8. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 81 B.9. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79
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 This document describes the Locator/Identifier Separation Protocol
architecture have noted that its use of a single numbering space (the (LISP), which provides a set of functions for routers to exchange
"IP address") for both host transport session identification and information used to map from non-routeable Endpoint Identifiers
network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). (EIDs) to routeable Routing Locators (RLOCs). It also defines a
A number of scaling benefits would be realized by separating the mechanism for these LISP routers to encapsulate IP packets addressed
current IP address into separate spaces for Endpoint Identifiers with EIDs for transmission across an Internet that uses RLOCs for
(EIDs) and Routing Locators (RLOCs); among them are: routing and forwarding.
1. Reduction of routing table size in the "default-free zone" (DFZ).
Use of a separate numbering space for RLOCs will allow them to be
assigned topologically (in today's Internet, RLOCs would be
assigned by providers at client network attachment points),
greatly improving aggregation and reducing the number of
globally-visible, routable prefixes.
2. More cost-effective multihoming for sites that connect to
different service providers where they can control their own
policies for packet flow into the site without using extra
routing table resources of core routers.
3. Easing of renumbering burden when clients change providers.
Because host EIDs are numbered from a separate, non-provider-
assigned and non-topologically-bound space, they do not need to
be renumbered when a client site changes its attachment points to
the network.
4. Traffic engineering capabilities that can be performed by network
elements and do not depend on injecting additional state into the
routing system. This will fall out of the mechanism that is used
to implement the EID/RLOC split (see Section 4).
5. Mobility without address changing. Existing mobility mechanisms
will be able to work in a locator/ID separation scenario. It
will be possible for a host (or a collection of hosts) to move to
a different point in the network topology either retaining its
home-based address or acquiring a new address based on the new
network location. A new network location could be a physically
different point in the network topology or the same physical
point of the topology with a different provider.
This draft describes protocol mechanisms to achieve the desired
functional separation. For flexibility, the mechanism used for
forwarding packets is decoupled from that used to determine EID to
RLOC mappings. This document covers the former. For the latter, see
[CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response
to and intended to address the problem statement that came out of the
RAWS effort [RFC4984].
The Routing and Addressing problem statement can be found in [RADIR].
This draft focuses on a router-based solution. Building the solution
into the network will facilitate incremental deployment of the
technology on the Internet. Note that while the detailed protocol
specification and examples in this document assume IP version 4
(IPv4), there is nothing in the design that precludes use of the same
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
RLOCs.
Related work on host-based solutions is described in Shim6 [RFC5533]
and HIP [RFC4423]. Related work on a router-based solution is
described in [GSE]. This draft attempts to not compete or overlap
with such solutions and the proposed protocol changes are expected to
complement a host-based mechanism when Traffic Engineering
functionality is desired.
Some of the design goals of this proposal include:
1. Require no hardware or software changes to end-systems (hosts).
2. Minimize required changes to Internet infrastructure.
3. Be incrementally deployable.
4. Require no router hardware changes.
5. Minimize the number of routers which have to be modified. In
particular, most customer site routers and no core routers
require changes.
6. Minimize router software changes in those routers which are
affected.
7. Avoid or minimize packet loss when EID-to-RLOC mappings need to
be performed.
There are 4 variants of LISP, which differ along a spectrum of strong
to weak dependence on the topological nature and possible need for
routability of EIDs. The variants are:
LISP 1: uses EIDs that are routable through the RLOC topology for
bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as
a prototyping mechanism for early protocol implementation. It is
now deprecated and SHOULD NOT be deployed.
LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC Creation of LISP was initially motivated by discussions during the
mappings; such routing is via a separate topology. IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
October, 2006 (see [RFC4984]). A key conclusion of the workshop was
that the Internet routing and addressing system was not scaling well
in the face of the explosive growth of new sites; one reason for this
poor scaling is the increasing number of multi-homed and other sites
that cannot be addressed as part of topologically- or provider-based
aggregated prefixes. Additional work that more completely described
the problem statement may be found in [RADIR].
LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are A basic observation, made many years ago in early networking research
implemented within the DNS. [LISP2] such as that documented in [CHIAPPA] and [RFC4984], is that using a
single address field for both identifying a device and for
determining where it is topologically located in the network requires
optimization along two conflicting axes: for routing to be efficient,
the address must be assigned topologically; for collections of
devices to be easily and effectively managed, without the need for
renumbering in response to topological change (such as that caused by
adding or removing attachment points to the network or by mobility
events), the address must explicitly not be tied to the topology.
LISP 3: uses non-routable EIDs that are used as lookup keys for a The approach that LISP takes to solving the routing scalability
new EID-to-RLOC mapping database. Use of Distributed Hash Tables problem is to replace IP addresses with two new types of numbers:
[DHTs] [LISPDHT] to implement such a database would be an area to Routing Locators (RLOCs), which are topologically assigned to network
explore. Other examples of new mapping database services are attachment points (and are therefore amenable to aggregation) and
[CONS], [ALT], [RPMD], [NERD], and [APT]. used for routing and forwarding of packets through the network; and
Endpoint Identifiers (EIDs), which are assigned independently from
the network topology, are used for numbering devices, and are
aggregated along administrative boundaries. LISP then defines
functions for mapping between the two numbering spaces and for
encapsulating traffic originated by devices using non-routeable EIDs
for transport across a network infrastructure that routes and
forwards using RLOCs. Both RLOCs and EIDs are syntactically-
identical to IP addresses; it is the semantics of how they are used
that differs.
This document on LISP 1.5, and LISP 3 variants, both of which rely on This document describes the protocol that implements these functions.
a router-based distributed cache and database for EID-to-RLOC The database which stores the mappings between EIDs and RLOCs is
mappings. The LISP 1.0 mechanism works but does not allow reduction explicitly a separate "module" to facilitate experimentation with a
of routing information in the default-free-zone of the Internet. The variety of approaches. One database design that is being developed
LISP 2 mechanisms are put on hold and may never come to fruition and prototyped as part of the LISP working group work is [ALT].
since it is not architecturally pure to have routing depend on Others that have been described but not implemented include [CONS],
directory and directory depend on routing. The LISP 3 mechanisms [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general-
will be documented elsewhere but may use the control-plane options purpose service interface for accessing a mapping database; this
specified in this specification. interface is intended to make the mapping database modular so that
different approaches can be tried without the need to modify
installed xTRs.
3. Definition of Terms 3. Definition of Terms
Provider Independent (PI) Addresses: an address block assigned from Provider Independent (PI) Addresses: PI addresses are an address
a pool where blocks are not associated with any particular block assigned from a pool where blocks are not associated with
location in the network (e.g. from a particular service provider), any particular location in the network (e.g. from a particular
and is therefore not topologically aggregatable in the routing service provider), and is therefore not topologically aggregatable
system. in the routing system.
Provider Assigned (PA) Addresses: a block of IP addresses that are Provider Assigned (PA) Addresses: PA addresses are an a address
assigned to a site by each service provider to which a site block assigned to a site by each service provider to which a site
connects. Typically, each block is sub-block of a service connects. Typically, each block is sub-block of a service
provider CIDR block and is aggregated into the larger block before provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
being advertised into the global Internet. Traditionally, IP is aggregated into the larger block before being advertised into
multihoming has been implemented by each multi-homed site the global Internet. Traditionally, IP multihoming has been
acquiring its own, globally-visible prefix. LISP uses only implemented by each multi-homed site acquiring its own, globally-
topologically-assigned and aggregatable address blocks for RLOCs, visible prefix. LISP uses only topologically-assigned and
eliminating this demonstrably non-scalable practice. aggregatable address blocks for RLOCs, eliminating this
demonstrably non-scalable practice.
Routing Locator (RLOC): the IPv4 or IPv6 address of an egress Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an
tunnel router (ETR). It is the output of a EID-to-RLOC mapping egress tunnel router (ETR). A RLOC is the output of a EID-to-RLOC
lookup. An EID maps to one or more RLOCs. Typically, RLOCs are mapping lookup. An EID maps to one or more RLOCs. Typically,
numbered from topologically-aggregatable blocks that are assigned RLOCs are numbered from topologically-aggregatable blocks that are
to a site at each point to which it attaches to the global assigned to a site at each point to which it attaches to the
Internet; where the topology is defined by the connectivity of global Internet; where the topology is defined by the connectivity
provider networks, RLOCs can be thought of as PA addresses. of provider networks, RLOCs can be thought of as PA addresses.
Multiple RLOCs can be assigned to the same ETR device or to Multiple RLOCs can be assigned to the same ETR device or to
multiple ETR devices at a site. multiple ETR devices at a site.
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for
used in the source and destination address fields of the first IPv6) value used in the source and destination address fields of
(most inner) LISP header of a packet. The host obtains a the first (most inner) LISP header of a packet. The host obtains
destination EID the same way it obtains an destination address a destination EID the same way it obtains an destination address
today, for example through a DNS lookup or SIP exchange. The today, for example through a Domain Name System (DNS) [RFC1034]
source EID is obtained via existing mechanisms used to set a lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
The source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts. located. An EID can be used by a host to refer to other hosts.
EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be
assigned in a hierarchical manner, independent of the network assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site may have site-local addition, an EID block assigned to a site may have site-local
structure (subnetting) for routing within the site; this structure structure (subnetting) for routing within the site; this structure
is not visible to the global routing system. When used in is not visible to the global routing system. When used in
discussions with other Locator/ID separation proposals, a LISP EID discussions with other Locator/ID separation proposals, a LISP EID
will be called a "LEID". Throughout this document, any references will be called a "LEID". Throughout this document, any references
to "EID" refers to an LEID. to "EID" refers to an LEID.
EID-prefix: A power-of-2 block of EIDs which are allocated to a EID-prefix: An EID-prefix is a power-of-two block of EIDs which are
site by an address allocation authority. EID-prefixes are allocated to a site by an address allocation authority. EID-
associated with a set of RLOC addresses which make up a "database prefixes are associated with a set of RLOC addresses which make up
mapping". EID-prefix allocations can be broken up into smaller a "database mapping". EID-prefix allocations can be broken up
blocks when an RLOC set is to be associated with the smaller EID- into smaller blocks when an RLOC set is to be associated with the
prefix. A globally routed address block (whether PI or PA) is not smaller EID-prefix. A globally routed address block (whether PI
an EID-prefix. However, a globally routed address block may be or PA) is not an EID-prefix. However, a globally routed address
removed from global routing and reused as an EID-prefix. A site block may be removed from global routing and reused as an EID-
that receives an explicitly allocated EID-prefix may not use that prefix. A site that receives an explicitly allocated EID-prefix
EID-prefix as a globally routed prefix assigned to RLOCs. may not use that EID-prefix as a globally routed prefix assigned
to RLOCs.
End-system: is an IPv4 or IPv6 device that originates packets with End-system: An end-system is an IPv4 or IPv6 device that originates
a single IPv4 or IPv6 header. The end-system supplies an EID packets with a single IPv4 or IPv6 header. The end-system
value for the destination address field of the IP header when supplies an EID value for the destination address field of the IP
communicating globally (i.e. outside of its routing domain). An header when communicating globally (i.e. outside of its routing
end-system can be a host computer, a switch or router device, or domain). An end-system can be a host computer, a switch or router
any network appliance. device, or any network appliance.
Ingress Tunnel Router (ITR): a router which accepts an IP packet Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP
with a single IP header (more precisely, an IP packet that does packet with a single IP header (more precisely, an IP packet that
not contain a LISP header). The router treats this "inner" IP does not contain a LISP header). The router treats this "inner"
destination address as an EID and performs an EID-to-RLOC mapping IP destination address as an EID and performs an EID-to-RLOC
lookup. The router then prepends an "outer" IP header with one of mapping lookup. The router then prepends an "outer" IP header
its globally-routable RLOCs in the source address field and the with one of its globally-routable RLOCs in the source address
result of the mapping lookup in the destination address field. field and the result of the mapping lookup in the destination
Note that this destination RLOC may be an intermediate, proxy address field. Note that this destination RLOC may be an
device that has better knowledge of the EID-to-RLOC mapping closer intermediate, proxy device that has better knowledge of the EID-
to the destination EID. In general, an ITR receives IP packets to-RLOC mapping closer to the destination EID. In general, an ITR
from site end-systems on one side and sends LISP-encapsulated IP receives IP packets from site end-systems on one side and sends
packets toward the Internet on the other side. LISP-encapsulated IP packets toward the Internet on the other
side.
Specifically, when a service provider prepends a LISP header for Specifically, when a service provider prepends a LISP header for
Traffic Engineering purposes, the router that does this is also Traffic Engineering purposes, the router that does this is also
regarded as an ITR. The outer RLOC the ISP ITR uses can be based regarded as an ITR. The outer RLOC the ISP ITR uses can be based
on the outer destination address (the originating ITR's supplied on the outer destination address (the originating ITR's supplied
RLOC) or the inner destination address (the originating hosts RLOC) or the inner destination address (the originating hosts
supplied EID). supplied EID).
TE-ITR: is an ITR that is deployed in a service provider network TE-ITR: A TE-ITR is an ITR that is deployed in a service provider
that prepends an additional LISP header for Traffic Engineering network that prepends an additional LISP header for Traffic
purposes. Engineering purposes.
Egress Tunnel Router (ETR): a router that accepts an IP packet Egress Tunnel Router (ETR): An ETR is a router that accepts an IP
where the destination address in the "outer" IP header is one of packet where the destination address in the "outer" IP header is
its own RLOCs. The router strips the "outer" header and forwards one of its own RLOCs. The router strips the "outer" header and
the packet based on the next IP header found. In general, an ETR forwards the packet based on the next IP header found. In
receives LISP-encapsulated IP packets from the Internet on one general, an ETR receives LISP-encapsulated IP packets from the
side and sends decapsulated IP packets to site end-systems on the Internet on one side and sends decapsulated IP packets to site
other side. ETR functionality does not have to be limited to a end-systems on the other side. ETR functionality does not have to
router device. A server host can be the endpoint of a LISP tunnel be limited to a router device. A server host can be the endpoint
as well. of a LISP tunnel as well.
TE-ETR: is an ETR that is deployed in a service provider network TE-ETR: A TE-ETR is an ETR that is deployed in a service provider
that strips an outer LISP header for Traffic Engineering purposes. network that strips an outer LISP header for Traffic Engineering
purposes.
xTR: is a reference to an ITR or ETR when direction of data flow is xTR: A xTR is a reference to an ITR or ETR when direction of data
not part of the context description. xTR refers to the router that flow is not part of the context description. xTR refers to the
is the tunnel endpoint. Used synonymously with the term "Tunnel router that is the tunnel endpoint. Used synonymously with the
Router". For example, "An xTR can be located at the Customer Edge term "Tunnel Router". For example, "An xTR can be located at the
(CE) router", meaning both ITR and ETR functionality is at the CE Customer Edge (CE) router", meaning both ITR and ETR functionality
router. is at the CE router.
EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on-
stores, tracks, and is responsible for timing-out and otherwise demand table in an ITR that stores, tracks, and is responsible for
validating EID-to-RLOC mappings. This cache is distinct from the timing-out and otherwise validating EID-to-RLOC mappings. This
full "database" of EID-to-RLOC mappings, it is dynamic, local to cache is distinct from the full "database" of EID-to-RLOC
the ITR(s), and relatively small while the database is mappings, it is dynamic, local to the ITR(s), and relatively small
distributed, relatively static, and much more global in scope. while the database is distributed, relatively static, and much
more global in scope.
EID-to-RLOC Database: a global distributed database that contains EID-to-RLOC Database: The EID-to-RLOC database is a global
all known EID-prefix to RLOC mappings. Each potential ETR distributed database that contains all known EID-prefix to RLOC
typically contains a small piece of the database: the EID-to-RLOC mappings. Each potential ETR typically contains a small piece of
mappings for the EID prefixes "behind" the router. These map to the database: the EID-to-RLOC mappings for the EID prefixes
one of the router's own, globally-visible, IP addresses. The same "behind" the router. These map to one of the router's own,
database mapping entries MUST be configured on all ETRs for a globally-visible, IP addresses. The same database mapping entries
given site. That is, the EID-prefixes for the site and locator- MUST be configured on all ETRs for a given site. That is, the
set for each EID-prefix MUST be the same on all ETRs so they EID-prefixes for the site and locator-set for each EID-prefix MUST
consistently send Map-Reply messages with the same database be the same on all ETRs so they consistently send Map-Reply
mapping contents. messages with the same database mapping contents.
Recursive Tunneling: when a packet has more than one LISP IP Recursive Tunneling: Recursive tunneling occurs when a packet has
header. Additional layers of tunneling may be employed to more than one LISP IP header. Additional layers of tunneling may
implement traffic engineering or other re-routing as needed. When be employed to implement traffic engineering or other re-routing
this is done, an additional "outer" LISP header is added and the as needed. When this is done, an additional "outer" LISP header
original RLOCs are preserved in the "inner" header. Any is added and the original RLOCs are preserved in the "inner"
references to tunnels in this specification refers to dynamic header. Any references to tunnels in this specification refers to
encapsulating tunnels and never are they statically configured. dynamic encapsulating tunnels and never are they statically
configured.
Reencapsulating Tunnels: when a packet has no more than one LISP IP Reencapsulating Tunnels: Reencapsulating tunneling occurs when a
header (two IP headers total) and when it needs to be diverted to packet has no more than one LISP IP header (two IP headers total)
new RLOC, an ETR can decapsulate the packet (remove the LISP and when it needs to be diverted to new RLOC, an ETR can
header) and prepends a new tunnel header, with new RLOC, on to the decapsulate the packet (remove the LISP header) and prepends a new
packet. Doing this allows a packet to be re-routed by the re- tunnel header, with new RLOC, on to the packet. Doing this allows
encapsulating router without adding the overhead of additional a packet to be re-routed by the re-encapsulating router without
tunnel headers. Any references to tunnels in this specification adding the overhead of additional tunnel headers. Any references
refers to dynamic encapsulating tunnels and never are they to tunnels in this specification refers to dynamic encapsulating
statically configured. tunnels and never are they statically configured.
LISP Header: a term used in this document to refer to the outer LISP Header: a term used in this document to refer to the outer
IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
header that follows the UDP header, an ITR prepends or an ETR header that follows the UDP header, an ITR prepends or an ETR
strips. strips.
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. An address family currently pertains to an encoding in a packet. An address family currently pertains to an
IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An
AFI value of 0 used in this specification indicates an unspecified AFI value of 0 used in this specification indicates an unspecified
encoded address where the the length of the address is 0 bytes encoded address where the length of the address is 0 bytes
following 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: A negative mapping entry, also known as a
EID-to-RLOC entry where an EID-prefix is advertised or stored with negative cache entry, is an EID-to-RLOC entry where an EID-prefix
no RLOCs. That is, the locator-set for the EID-to-RLOC entry is is advertised or stored with no RLOCs. That is, the locator-set
empty or has an encoded locator count of 0. This type of entry for the EID-to-RLOC entry is empty or has an encoded locator count
could be used to describe a prefix from a non-LISP site, which is of 0. This type of entry could be used to describe a prefix from
explicitly not in the mapping database. There are a set of well a non-LISP site, which is explicitly not in the mapping database.
defined actions that are encoded in a Negative Map-Reply. There are a set of well defined actions that are encoded in a
Negative Map-Reply.
Data Probe: a LISP-encapsulated data packet where the inner header Data Probe: A data-probe is a LISP-encapsulated data packet where
destination address equals the outer header destination address the inner header destination address equals the outer header
used to trigger a Map-Reply by a decapsulating ETR. In addition, destination address used to trigger a Map-Reply by a decapsulating
the original packet is decapsulated and delivered to the ETR. In addition, the original packet is decapsulated and
destination host. A Data Probe is used in some of the mapping delivered to the destination host. A Data Probe is used in some
database designs to "probe" or request a Map-Reply from an ETR; in of the mapping database designs to "probe" or request a Map-Reply
other cases, Map-Requests are used. See each mapping database from an ETR; in other cases, Map-Requests are used. See each
design for details. mapping database design for details.
Proxy ITR (PITR): also known as a PTR is defined and described in Proxy ITR (PITR): A PITR is also known as a PTR is defined and
[INTERWORK], a PITR acts like an ITR but does so on behalf of non- described in [INTERWORK], a PITR acts like an ITR but does so on
LISP sites which send packets to destinations at LISP sites. behalf of non-LISP sites which send packets to destinations at
LISP sites.
Proxy ETR (PETR): is defined and described in [INTERWORK], a PETR Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a
acts like an ETR but does so on behalf of LISP sites which send PETR acts like an ETR but does so on behalf of LISP sites which
packets to destinations at non-LISP sites. send packets to destinations at non-LISP sites.
Route-returnability: is an assumption that the underlying routing Route-returnability: is an assumption that the underlying routing
system will deliver packets to the destination. When combined system will deliver packets to the destination. When combined
with a nonce that is provided by a sender and returned by a with a nonce that is provided by a sender and returned by a
receiver limits off-path data insertion. receiver limits off-path data insertion.
LISP site: is a set of routers in an edge network that are under a LISP site: is a set of routers in an edge network that are under a
single technical administration. LISP routers which reside in the single technical administration. LISP routers which reside in the
edge network are the demarcation points to separate the edge edge network are the demarcation points to separate the edge
network from the core network. network from the core network.
Client-side: a term used in this document to indicate a connection
initiation attempt by an EID. The ITR(s) at the LISP site are the
first to get involved in obtaining database map cache entries by
sending Map-Request messages.
Server-side: a term used in this document to indicate a connection
initiation attempt is being accepted for a destination EID. The
ETR(s) at the destination LISP site are the first to send Map-
Replies to the source site initiating the connection. The ETR(s)
at this destination site can obtain mappings by gleaning
information from Map-Requests, Data-Probes, or encapsulated
packets.
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
referred to as Routing Locators (RLOCs). Most routers along a path referred to as Routing Locators (RLOCs). Most routers along a path
between two hosts will not change; they continue to perform routing/ between two hosts will not change; they continue to perform routing/
forwarding lookups on the destination addresses. For routers between forwarding lookups on the destination addresses. For routers between
the source host and the ITR as well as routers from the ETR to the the source host and the ITR as well as routers from the ETR to the
destination host, the destination address is an EID. For the routers destination host, the destination address is an EID. For the routers
between the ITR and the ETR, the destination address is an RLOC. between the ITR and the ETR, the destination address is an RLOC.
This design introduces "Tunnel Routers", which prepends LISP headers Another key LISP concept is the "Tunnel Router". A tunnel router
on host-originated packets and strip them prior to final delivery to prepends LISP headers on host-originated packets and strip them prior
their destination. The IP addresses in this "outer header" are to final delivery to their destination. The IP addresses in this
RLOCs. During end-to-end packet exchange between two Internet hosts, "outer header" are RLOCs. During end-to-end packet exchange between
an ITR prepends a new LISP header to each packet and an egress tunnel two Internet hosts, an ITR prepends a new LISP header to each packet
router strips the new header. The ITR performs EID-to-RLOC lookups and an egress tunnel router strips the new header. The ITR performs
to determine the routing path to the the ETR, which has the RLOC as EID-to-RLOC lookups to determine the routing path to the ETR, which
one of its IP addresses. has the RLOC as one of its IP addresses.
Some basic rules governing LISP are: Some basic rules governing LISP are:
o End-systems (hosts) only send to addresses which are EIDs. They o End-systems (hosts) only send to addresses which are EIDs. They
don't know addresses are EIDs versus RLOCs but assume packets get don't know addresses are EIDs versus RLOCs but assume packets get
to LISP routers, which in turn, deliver packets to the destination to LISP routers, which in turn, deliver packets to the destination
the end-system has specified. the end-system has specified.
o EIDs are always IP addresses assigned to hosts. o EIDs are always IP addresses assigned to hosts.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
using RLOCs to terminate eBGP sessions to routers outside the using RLOCs to terminate eBGP sessions to routers outside the
site. site.
o EIDs are not expected to be usable for global end-to-end o EIDs are not expected to be usable for global end-to-end
communication in the absence of an EID-to-RLOC mapping operation. communication in the absence of an EID-to-RLOC mapping operation.
They are expected to be used locally for intra-site communication. They are expected to be used locally for intra-site communication.
o EID prefixes are likely to be hierarchically assigned in a manner o EID prefixes are likely to be hierarchically assigned in a manner
which is optimized for administrative convenience and to which is optimized for administrative convenience and to
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
dependent on the network topology. independent of 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 TE-ITR
router (i.e. TE-ITR) when re-routing of the path for a packet is when re-routing of the path for a packet is desired. An obvious
desired. An obvious instance of this would be an ISP router that instance of this would be an ISP router that needs to perform traffic
needs to perform traffic engineering for packets flowing through its engineering for packets flowing through its network. In such a
network. In such a situation, termed Recursive Tunneling, an ISP situation, termed Recursive Tunneling, an ISP transit acts as an
transit acts as an additional ingress tunnel router and the RLOC it additional ingress tunnel router and the RLOC it uses for the new
uses for the new prepended header would be either a TE-ETR within the prepended header would be either a TE-ETR within the ISP (along
ISP (along intra-ISP traffic engineered path) or a TE-ETR within intra-ISP traffic engineered path) or a TE-ETR within another ISP (an
another ISP (an inter-ISP traffic engineered path, where an agreement inter-ISP traffic engineered path, where an agreement to build such a
to build such a path exists). path exists).
This specification mandates that no more than two LISP headers get In order to avoid excessive packet overhead as well as possible
prepended to a packet. This avoids excessive packet overhead as well encapsulation loops, this document mandates that a maximum of two
as possible encapsulation loops. It is believed two headers is LISP headers can be prepended to a packet. It is believed two
sufficient, where the first prepended header is used at a site for headers is sufficient, where the first prepended header is used at a
Location/Identity separation and second prepended header is used site for Location/Identity separation and second prepended header is
inside a service provider for Traffic Engineering purposes. used inside a service provider for Traffic Engineering purposes.
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
For example, the ITR for a particular end-to-end packet exchange For example, the ITR for a particular end-to-end packet exchange
might be the first-hop or default router within a site for the source might be the first-hop or default router within a site for the source
host. Similarly, the egress tunnel router might be the last-hop host. Similarly, the egress tunnel router might be the last-hop
router directly-connected to the destination host. Another example, router directly-connected to the destination host. Another example,
perhaps for a VPN service out-sourced to an ISP by a site, the ITR perhaps for a VPN service out-sourced to an ISP by a site, the ITR
could be the site's border router at the service provider attachment could be the site's border router at the service provider attachment
point. Mixing and matching of site-operated, ISP-operated, and other point. Mixing and matching of site-operated, ISP-operated, and other
tunnel routers is allowed for maximum flexibility. See Section 8 for tunnel routers is allowed for maximum flexibility. See Section 8 for
skipping to change at page 14, line 23 skipping to change at page 14, line 23
o Each site is multi-homed, so each tunnel router has an address o Each site is multi-homed, so each tunnel router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular tunnel router is attached. provider to which that particular tunnel router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively, but the source and destination can be destination, respectively, but the source and destination can be
located anywhere in LISP site. located anywhere in LISP site.
o Map-Requests can be sent on the underlying routing system topology o Map-Requests can be sent on the underlying routing system topology
(LISP 1.0) or over an alternative topology [ALT]. or over an alternative topology [ALT].
o Map-Replies are sent on the underlying routing system topology. o Map-Replies are sent on the underlying routing system topology.
Client host1.abc.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 the destination EID. The locally- returned. This address is the destination EID. The locally-
assigned address of host1.abc.com is used as the source EID. An assigned address of host1.abc.com is used as the source EID. An
IPv4 or IPv6 packet is built and forwarded through the LISP site IPv4 or IPv6 packet is built and forwarded through the LISP site
as a normal IP packet until it reaches a LISP ITR. as a normal IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the EID destination to an RLOC 2. The LISP ITR must be able to map the EID destination to an RLOC
of one of the ETRs at the destination site. The specific method of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See [ALT] or used to do this is not described in this example. See [ALT] or
[CONS] for possible solutions. [CONS] for possible solutions.
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
rate-limited. rate-limited.
4. In LISP 1.0, the Map-Request packet is routed through the 4. When an alternate mapping system is not in use, the Map-Request
underlying routing system. In LISP 1.5, the Map-Request packet packet is routed through the underlying routing system.
is routed on an alternate logical topology. In either case, when Otherwise, the Map-Request packet is routed on an alternate
the Map-Request arrives at one of the ETRs at the destination logical topology. In either case, when the Map-Request arrives
site, it will process the packet as a control message. at one of the ETRs at the destination site, it will process the
packet as a control message.
5. The ETR looks at the destination EID of the Map-Request and 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- matches it against the prefixes in the ETR's configured EID-to-
RLOC mapping database. This is the list of EID-prefixes the ETR 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, is supporting for the site it resides in. If there is no match,
the Map-Request is dropped. Otherwise, a LISP Map-Reply is the Map-Request is dropped. Otherwise, a LISP Map-Reply is
returned to the ITR. returned to the ITR.
6. The ITR receives the Map-Reply message, parses the message (to 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 stored in the ITR's EID-to-
RLOC mapping cache (this is the on-demand cache, the cache where RLOC mapping cache. Note that the map cache is an on-demand
entries time out due to inactivity). cache. An ITR will manage its map cache in such a way that
optimizes for its resource constraints.
7. 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.
8. 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
ITR and the ETR may also influence the decision the other makes in ITR and the ETR may also influence the decision the other makes in
selecting an RLOC. See Section 6 for more details. selecting an RLOC. See Section 6 for more details.
5. Tunneling Details 5. LISP Encapsulation Details
This section describes the LISP Data Message which defines the
tunneling header used to encapsulate IPv4 and IPv6 packets which
contain EID addresses. Even though the following formats illustrate
IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2
combinations are supported as well.
Since additional tunnel headers are prepended, the packet becomes Since additional tunnel headers are prepended, the packet becomes
larger and in theory can exceed the MTU of any link traversed from larger and can exceed the MTU of any link traversed from the ITR to
the ITR to the ETR. It is recommended, in IPv4 that packets do not the ETR. It is recommended in IPv4 that packets do not get
get fragmented as they are encapsulated by the ITR. Instead, the fragmented as they are encapsulated by the ITR. Instead, the packet
packet is dropped and an ICMP Too Big message is returned to the is dropped and an ICMP Too Big message is returned to the source.
source.
Based on informal surveys of large ISP traffic patterns, it appears
that most transit paths can accommodate a path MTU of at least 4470
bytes. The exceptions, in terms of data rate, number of hosts
affected, or any other metric are expected to be vanishingly small.
To address MTU concerns, mainly raised on the RRG mailing list, the
LISP deployment process will include collecting data during its pilot
phase to either verify or refute the assumption about minimum
available MTU. If the assumption proves true and transit networks
with links limited to 1500 byte MTUs are corner cases, it would seem
more cost-effective to either upgrade or modify the equipment in
those transit networks to support larger MTUs or to use existing
mechanisms for accommodating packets that are too large.
For this reason, there is currently no plan for LISP to add any new This specification recommends that implementations support for one of
additional, complex mechanism for implementing fragmentation and the proposed fragmentation and reassembly schemes. These two simple
reassembly in the face of limited-MTU transit links. If analysis existing schemes are detailed in Section 5.4.
during LISP pilot deployment reveals that the assumption of
essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect,
then LISP can be modified prior to protocol standardization to add
support for one of the proposed fragmentation and reassembly schemes.
Note that two simple existing schemes are detailed in Section 5.4.
5.1. LISP IPv4-in-IPv4 Header Format 5.1. LISP IPv4-in-IPv4 Header Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 14 skipping to change at page 19, line 7
r + + r + +
| | | |
^ + Destination EID + ^ + Destination EID +
\ | | \ | |
\ + + \ + +
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Tunnel Header Field Descriptions 5.3. Tunnel Header Field Descriptions
Inner Header: is the inner header, preserved from the datagram Inner Header: The inner header is the header on the datagram
received from the originating host. The source and destination IP received from the originating host. The source and destination IP
addresses are EIDs. addresses are EIDs.
Outer Header: is the outer header prepended by an ITR. The address Outer Header: The outer header is a new header prepended by an ITR.
fields contain RLOCs obtained from the ingress router's EID-to- The address fields contain RLOCs obtained from the ingress
RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. router's EID-to-RLOC cache. The IP protocol number is "UDP (17)"
The DF bit of the Flags field is set to 0 when the method in from [RFC0768]. The DF bit of the Flags field is set to 0 when
Section 5.4.1 is used and set to 1 when the method in the method in Section 5.4.1 is used and set to 1 when the method
Section 5.4.2 is used. in Section 5.4.2 is used.
UDP Header: contains a ITR selected source port when encapsulating a UDP Header: The UDP header contains a ITR selected source port when
packet. See Section 6.4 for details on the hash algorithm used to encapsulating a packet. See Section 6.5 for details on the hash
select a source port based on the 5-tuple of the inner header. algorithm used to select a source port based on the 5-tuple of the
The destination port MUST be set to the well-known IANA assigned inner header. The destination port MUST be set to the well-known
port value 4341. IANA assigned port value 4341.
UDP Checksum: this field SHOULD be transmitted as zero by an ITR for UDP Checksum: The UDP checksum field SHOULD be transmitted as zero
either IPv4 [RFC0768] or IPv6 encapsulation [UDP-TUNNELS]. When a by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
packet with a zero UDP checksum is received by an ETR, the ETR [UDP-TUNNELS]. When a packet with a zero UDP checksum is received
MUST accept the packet for decapsulation. When an ITR transmits a by an ETR, the ETR MUST accept the packet for decapsulation. When
non-zero value for the UDP checksum, it MUST send a correctly an ITR transmits a non-zero value for the UDP checksum, it MUST
computed value in this field. When an ETR receives a packet with send a correctly computed value in this field. When an ETR
a non-zero UDP checksum, it MAY choose to verify the checksum receives a packet with a non-zero UDP checksum, it MAY choose to
value. If it chooses to perform such verification, and the verify the checksum value. If it chooses to perform such
verification fails, the packet MUST be silently dropped. If the verification, and the verification fails, the packet MUST be
ETR chooses not to perform the verification, or performs the silently dropped. If the ETR chooses not to perform the
verification successfully, the packet MUST be accepted for verification, or performs the verification successfully, the
decapsulation. The handling of UDP checksums for all tunneling packet MUST be accepted for decapsulation. The handling of UDP
protocols, including LISP, is under active discussion within the checksums for all tunneling protocols, including LISP, is under
IETF. When that discussion concludes, any necessary changes will active discussion within the IETF. When that discussion
be made to align LISP with the outcome of the broader discussion. concludes, any necessary changes will 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: The UDP length field is for an IPv4 encapsulated packet,
Length plus the UDP and LISP header lengths are used. For an IPv6 the inner header Total Length plus the UDP and LISP header lengths
encapsulated packet, the inner header Payload Length plus the size are used. For an IPv6 encapsulated packet, the inner header
of the IPv6 header (40 bytes) plus the size of the UDP and LISP Payload Length plus the size of the IPv6 header (40 bytes) plus
headers are used. The UDP header length is 8 bytes. the size of the UDP and LISP 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: The N bit is the nonce-present bit. When this bit is set to 1,
low-order 24-bits of the first 32-bits of the LISP header contains the low-order 24-bits of the first 32-bits of the LISP header
a Nonce. See Section 6.3.1 for details. Both N and V bits MUST contains a Nonce. See Section 6.3.1 for details. Both N and V
NOT be set in the same packet. If they are, a decapsulating ETR bits MUST NOT be set in the same packet. If they are, a
MUST treat the "Nonce/Map-Version" field as having a Nonce value decapsulating ETR MUST treat the "Nonce/Map-Version" field as
present. having a Nonce value present.
L: this is the Locator-Status-Bits field enabled bit. When this bit L: The L bit is the Locator-Status-Bits field enabled bit. When this
is set to 1, the Locator-Status-Bits in the second 32-bits of the bit is set to 1, the Locator-Status-Bits in the second 32-bits of
LISP header are in use. the LISP header are in use.
x 1 x x 0 x x x x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Status Bits | | Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: this is the echo-nonce-request bit. When this bit is set to 1, E: The E bit is the echo-nonce-request bit. When this bit is set to
the N bit MUST be 1. This bit SHOULD be ignored and has no 1, 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 6.3.1 for meaning when the N bit is set to 0. See Section 6.3.1 for
details. details.
V: this is the Map-Version present bit. When this bit is set to 1, V: The B bit is the Map-Version present bit. When this bit is set to
the N bit MUST be 0. Refer to Section 6.5.3 for more details. 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details.
This bit indicates that the first 4 bytes of the LISP header is This bit indicates that the first 4 bytes of the LISP header is
encoded as: encoded as:
0 x 0 1 x x x x 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator Status Bits | | Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: this is the Instance ID bit. See Section 5.5 for more details. I: The I bit is the Instance ID bit. See Section 5.5 for more
When this bit is set to 1, the Locator Status Bits field is details. When this bit is set to 1, the Locator Status Bits field
reduced to 8-bits and the high-order 24-bits are used as an 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 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 are transmitted as zero and ignored on receipt. The format of the
last 4 bytes of the LISP header would look like: last 4 bytes of the LISP header would look like:
x x x x 1 x x x x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs | | Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: this 3-bit field is reserved for future flag use. It is set flags: The flags field is a 3-bit field is reserved for future flag
to 0 on transmit and ignored on receipt. use. It is set to 0 on transmit and ignored on receipt.
LISP Nonce: is a 24-bit value that is randomly generated by an ITR LISP Nonce: The LISP nonce field is a 24-bit value that is randomly
when the N-bit is set to 1. The nonce is also used when the E-bit generated by an ITR when the N-bit is set to 1. The nonce is also
is set to request the nonce value to be echoed by the other side used when the E-bit is set to request the nonce value to be echoed
when packets are returned. When the E-bit is clear but the N-bit by the other side when packets are returned. When the E-bit is
is set, a remote ITR is either echoing a previously requested clear but the N-bit is set, a remote ITR is either echoing a
echo-nonce or providing a random nonce. See Section 6.3.1 for previously requested echo-nonce or providing a random nonce. See
more details. Section 6.3.1 for more details.
LISP Locator Status Bits: in the LISP header are set by an ITR to LISP Locator Status Bits: The locator status bits field in the LISP
indicate to an ETR the up/down status of the Locators in the header is set by an ITR to indicate to an ETR the up/down status
source site. Each RLOC in a Map-Reply is assigned an ordinal of the Locators in the source site. Each RLOC in a Map-Reply is
value from 0 to n-1 (when there are n RLOCs in a mapping entry). assigned an ordinal value from 0 to n-1 (when there are n RLOCs in
The Locator Status Bits are numbered from 0 to n-1 from the least a mapping entry). The Locator Status Bits are numbered from 0 to
significant bit of field. The field is 32-bits when the I-bit is n-1 from the least significant bit of field. The field is 32-bits
set to 0 and is 8 bits when the I-bit is set to 1. When a Locator when the I-bit is set to 0 and is 8 bits when the I-bit is set to
Status Bit is set to 1, the ITR is indicating to the ETR the RLOC 1. When a Locator Status Bit is set to 1, the ITR is indicating
associated with the bit ordinal has up status. See Section 6.3 to the ETR the RLOC associated with the bit ordinal has up status.
for details on how an ITR can determine the status of other ITRs See Section 6.3 for details on how an ITR can determine the status
at the same site. When a site has multiple EID-prefixes which of other ITRs at the same site. When a site has multiple EID-
result in multiple mappings (where each could have a different prefixes which result in multiple mappings (where each could have
locator-set), the Locator Status Bits setting in an encapsulated a different locator-set), the Locator Status Bits setting in an
packet MUST reflect the mapping for the EID-prefix that the inner- encapsulated packet MUST reflect the mapping for the EID-prefix
header source EID address matches. that the inner-header source EID address matches.
When doing Recursive Tunneling or ITR/PTR encapsulation: When doing ITR/PITR 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).
When doing Re-encapsulated Tunneling: When doing ETR/PETR decapsulation:
o The new outer header Time to Live field SHOULD be copied from the o The inner header Time to Live field (or Hop Limit field, in case
stripped outer header Time to Live field. of IPv6) SHOULD be copied from the outer header Time to Live
field, when the Time to Live field of the outer header is less
than the Time to Live of the inner header. Failing to perform
this check can cause the Time to Live of the inner header to
increment across encapsulation/decapsulation cycle. This check is
also performed when doing initial encapsulation when a packet
comes to an ITR or PITR destined for a LISP site.
o The new outer header Type of Service field SHOULD be copied from o The inner header Type of Service field (or the Traffic Class
the stripped OH header Type of Service field (with one caveat, see field, in the case of IPv6) SHOULD be copied from the outer header
below). Type of Service field (with one caveat, see below).
Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
after decapsulating, the net effect of this is that the new outer
header will carry the same Time to Live as the old outer header.
Copying the TTL serves two purposes: first, it preserves the distance Copying the TTL serves two purposes: first, it preserves the distance
the host intended the packet to travel; second, and more importantly, the host intended the packet to travel; second, and more importantly,
it provides for suppression of looping packets in the event there is it provides for suppression of looping packets in the event there is
a loop of concatenated tunnels due to misconfiguration. a loop of concatenated tunnels due to misconfiguration. See
Section 9.3 for TTL exception handling for traceroute packets.
The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
field and the IPv6 Traffic Class field [RFC3168]. The ECN field field and the IPv6 Traffic Class field [RFC3168]. The ECN field
requires special treatment in order to avoid discarding indications requires special treatment in order to avoid discarding indications
of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN
field from the inner header to the outer header. Re-encapsulation field from the inner header to the outer header. Re-encapsulation
MUST copy the 2-bit ECN field from the stripped outer header to the MUST copy the 2-bit ECN field from the stripped outer header to the
new outer header. If the ECN field contains a congestion indication new outer header. If the ECN field contains a congestion indication
codepoint (the value is '11', the Congestion Experienced (CE) codepoint (the value is '11', the Congestion Experienced (CE)
codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
the stripped outer header to the surviving inner header that is used the stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR. These requirements preserve to forward the packet beyond the ETR. These requirements preserve
Congestion Experienced (CE) indications when a packet that uses ECN Congestion Experienced (CE) indications when a packet that uses ECN
traverses a LISP tunnel and becomes marked with a CE indication due traverses a LISP tunnel and becomes marked with a CE indication due
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 This section proposes two simple mechanisms to deal with packets that
serious than expected, this section proposes 2 simple mechanisms to exceed the path MTU between the ITR and ETR.
deal with large packets. One is stateless using IP fragmentation and
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 used since
well since it is a local decision in the ITR regarding how to deal it is a local decision in the ITR regarding how to deal with MTU
with MTU issues. Sites can interoperate with differing mechanisms. issues, and 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 below referring 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 like to receive from a source
its site. inside of its site.
2. Define L to be the maximum size, in bytes, a packet of size S 2. Define L to be the maximum size, in bytes, a packet of size S
would be after the ITR prepends the LISP header, UDP header, and would be after the ITR prepends the LISP header, UDP header, and
outer network layer header of size H. outer network layer header of size H.
3. Calculate: S + H = L. 3. Calculate: S + H = L.
When an ITR receives a packet from a site-facing interface and adds H When an ITR receives a packet from a site-facing interface and adds H
bytes worth of encapsulation to yield a packet size greater than L bytes worth of encapsulation to yield a packet size greater than L
bytes, it resolves the MTU issue by first splitting the original bytes, it resolves the MTU issue by first splitting the original
packet into 2 equal-sized fragments. A LISP header is then prepended packet into 2 equal-sized fragments. A LISP header is then prepended
to each fragment. This will ensure that the new, encapsulated to each fragment. The size of the encapsulated fragments is then
packets are of size (S/2 + H), which is always below the effective (S/2 + H), which is less than the ITR's estimate of the path MTU
tunnel MTU. between the ITR and its correspondent ETR.
When an ETR receives encapsulated fragments, it treats them as two When an ETR receives encapsulated fragments, it treats them as two
individually encapsulated packets. It strips the LISP headers then individually encapsulated packets. It strips the LISP headers then
forwards each fragment to the destination host of the destination forwards each fragment to the destination host of the destination
site. The two fragments are reassembled at the destination host into site. The two fragments are reassembled at the destination host into
the single IP datagram that was originated by the source host. the single IP datagram that was originated by the source host.
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
skipping to change at page 24, line 40 skipping to change at page 24, line 49
the address encoding can aid in making the entire AFI based address the address encoding can aid in making the entire AFI based address
unique. See [LCAF] for details for a possible address encoding. The unique. See [LCAF] for details for a possible address encoding. The
LCAF encoding is an area for further study. LCAF encoding is an area for further study.
An Instance ID can be carried in a LISP encapsulated packet. An ITR 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 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 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 copied to the Instance ID field of the LISP header and the I-bit is
set to 1. set to 1.
When an ETR decapsulate a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup. to use for the inner destination EID lookup.
Some examples of the 24-bit value to copy or map into the Instance ID For example, a 802.1Q VLAN tag or VPN identifier could be used as a
field could be a 802.1Q VLAN tag or a configured VRF-ID value. 24-bit Instance ID.
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 33 skipping to change at page 27, line 33
set to 4342 and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking data packet.
The UDP Length field will reflect the length of the UDP header and The UDP Length field will reflect the length of the UDP header and
the LISP Message payload. the LISP Message payload.
The UDP Checksum is computed and set to non-zero for Map-Request, The UDP Checksum is computed and set to non-zero for Map-Request,
Map-Reply, Map-Register and ECM control messages. It MUST be checked Map-Reply, Map-Register and ECM control messages. It MUST be checked
on receipt and if the checksum fails, the packet MUST be dropped. on receipt and if the checksum fails, the packet MUST be dropped.
LISP-CONS [CONS] use TCP to send LISP control messages. The format LISP-CONS [CONS] uses TCP to send LISP control messages. The format
of control messages includes the UDP header so the checksum and of control messages includes the UDP header so the checksum and
length fields can be used to protect and delimit message boundaries. length fields can be used to protect and delimit message boundaries.
This main LISP specification is the authoritative source for message This main LISP specification is the authoritative source for message
format definitions for the Map-Request and Map-Reply messages. format definitions for the Map-Request and Map-Reply messages.
6.1.1. LISP Packet Type Allocations 6.1.1. LISP Packet Type Allocations
This section will be the authoritative source for allocating LISP This section will be the authoritative source for allocating LISP
Type values. Current allocations are: Type values. Current allocations are:
skipping to change at page 28, line 19 skipping to change at page 29, line 19
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: This is the probe-bit which indicates that a Map-Request SHOULD be P: This is the probe-bit which indicates that a Map-Request SHOULD be
treated as a locator reachability probe. The receiver SHOULD treated as a locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating the respond with a Map-Reply with the probe-bit set, indicating the
Map-Reply is a locator reachability probe reply, with the nonce Map-Reply is a locator reachability probe reply, with the nonce
copied from the Map-Request. See Section 6.3.2 for more details. copied from the Map-Request. See Section 6.3.2 for more details.
S: This is the SMR bit. See Section 6.5.2 for details. S: This is the SMR bit. See Section 6.6.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 IRC: This 5-bit field is the ITR-RLOC Count which encodes the
of (ITR-RLOC-AFI, ITR-RLOC Address) fields present in this additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
message. Multiple ITR-RLOC Address fields are used so a Map- present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-
Replier can select which destination address to use for a Map- Address) pair must always be encoded. Multiple ITR-RLOC Address
Reply. The IRC value ranges from 0 to 31, where IRC value 0 means fields are used so a Map-Replier can select which destination
an ITR-RLOC address count of 1, an IRC value of 1 means an ITR- address to use for a Map-Reply. The IRC value ranges from 0 to
RLOC address count of 2, and so on up to an IRC value of 31, which 31, and for a value of 1, there are 2 ITR-RLOC addresses encoded
means an ITR-RLOC address count of 32. and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.
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.
skipping to change at page 29, line 8 skipping to change at page 30, line 8
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.
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, an AFI value 0 is used and this field is of zero
length.
ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that
follows this field. follows this field.
ITR-RLOC Address: Used to give the ETR the option of selecting the ITR-RLOC Address: Used to give the ETR the option of selecting the
destination address from any address family for the Map-Reply destination address from any address family for the Map-Reply
message. This address MUST be a routable RLOC address. message. This address MUST be a routable RLOC address of the
sender of the Map-Request message.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
EID-prefix-AFI: Address family of EID-prefix according to [RFC5226] 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
message. message.
Map-Reply Record: When the M bit is set, this field is the size of Map-Reply Record: When the M bit is set, this field is the size of a
the "Record" field in the Map-Reply format. This Map-Reply record single "Record" in the Map-Reply format. This Map-Reply record
contains the EID-to-RLOC mapping entry associated with the Source contains the EID-to-RLOC mapping entry associated with the Source
EID. This allows the ETR which will receive this Map-Request to EID. This allows the ETR which will receive this Map-Request to
cache the data if it chooses to do so. cache the data if it chooses to do so.
Mapping Protocol Data: See [CONS] or [ALT] for details. This field Mapping Protocol Data: See [CONS] for details. This field is
is optional and present when the UDP length indicates there is optional and present when the UDP length indicates there is enough
enough space in the packet to include it. 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 latter 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
skipping to change at page 30, line 4 skipping to change at page 31, line 6
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 latter 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 an ITR/PITR selected 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 One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
be filled in by the ITR. The number of fields (minus 1) encoded MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST
be placed in the IRC field. The ITR MAY include all locally be placed in the IRC field. The ITR MAY include all locally
configured locators in this list or just provide one locator address configured locators in this list or just provide one locator address
from each address family it supports. If the ITR erroneously from each address family it supports. If the ITR erroneously
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
skipping to change at page 32, line 33 skipping to change at page 33, line 33
ACT: This 3-bit field describes negative Map-Reply actions. These ACT: This 3-bit field describes negative Map-Reply actions. These
bits are used only when the 'Locator Count' field is set to 0. bits are used only when the 'Locator Count' field is set to 0.
The action bits are encoded only in Map-Reply messages. The The action bits are encoded only in Map-Reply messages. The
actions defined are used by an ITR or PTR when a destination EID actions defined are used by an ITR or PTR when a destination EID
matches a negative mapping cache entry. Unassigned values should matches a negative mapping cache entry. Unassigned values should
cause a map-cache entry to be created and, when packets match this cause a map-cache entry to be created and, when packets match this
negative cache entry, they will be dropped. The current assigned negative cache entry, they will be dropped. The current assigned
values are: values are:
(0) Drop: The packet is dropped silently. (0) No-Action: The map-cache is kept alive and packet
encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Drop: A packet that matches this map-cache entry is dropped.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent by a UDP-based message is always
set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a
Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the
Authoritative bit is set to 0. This indicates to requesting ITRs Authoritative bit is set to 0. This indicates to requesting ITRs
that the Map-Reply was not originated by a LISP node managed at that the Map-Reply was not originated by a LISP node managed at
the site that owns the EID-prefix. the site that owns the EID-prefix.
Map-Version Number: When this 12-bit value is non-zero the Map-Reply Map-Version Number: When this 12-bit value is non-zero the Map-Reply
sender is informing the ITR what the version number is for the sender is informing the ITR what the version number is for the
EID-record contained in the Map-Reply. The ETR can allocate this EID-record contained in the Map-Reply. The ETR can allocate this
number internally but MUST coordinate this value with other ETRs number internally but MUST coordinate this value with other ETRs
for the site. When this value is 0, there is no versioning for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Section 6.5.3 for more Map-Request and Map-Register messages. See Section 6.6.3 for more
details. details.
EID-AFI: Address family of EID-prefix according to [RFC5226]. 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 relative weight of total unicast packets that match
mapping entry. If a non-zero weight value is used for any RLOC, the mapping entry. If a non-zero weight value is used for any
then all RLOCs MUST use a non-zero weight value and then the sum RLOC, then all RLOCs MUST use a non-zero weight value and then the
of all weight values MUST equal 100. If a zero value is used for sum of all weight values MUST equal 100. If a zero value is used
any RLOC weight, then all weights MUST be zero and the receiver of for any RLOC weight, then all weights MUST be zero and the
the Map-Reply will decide how to load-split traffic. See receiver of the Map-Reply will decide how to load-split traffic.
Section 6.4 for a suggested hash algorithm to distribute load See Section 6.5 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.
a single RLOC exists in a mapping entry, the weight value MUST be
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 relative
of total number of trees build to the source site identified by weight of total number of trees built to the source site
the EID-prefix. If a non-zero weight value is used for any RLOC, identified by the EID-prefix. If a non-zero weight value is used
then all RLOCs MUST use a non-zero weight value and then the sum for any RLOC, then all RLOCs MUST use a non-zero weight value and
of all weight values MUST equal 100. If a zero value is used for then the sum of all weight values MUST equal 100. If a zero value
any RLOC weight, then all weights MUST be zero and the receiver of is used for any RLOC weight, then all weights MUST be zero and the
the Map-Reply will decide how to distribute multicast state across receiver of the Map-Reply will decide how to distribute multicast
ITRs. state across 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 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 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 proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
0 for all locators in this locator-set. 0 for all locators in this locator-set.
p: when this bit is set, an ETR informs the RLOC-probing ITR that the 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- 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- probed and may be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular locator, MUST use Reply. An ITR that RLOC-probes a particular locator, MUST use
this locator for retrieving the data structure used to store the this locator for retrieving the data structure used to store the
fact that the locator is reachable. The "p" bit is set for a fact that the locator is reachable. The "p" bit is set for a
single locator in the same locator set. If an implementation sets single locator in the same locator set. If an implementation sets
more than one "p" bit erroneously, the receiver of the Map-Reply 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 MUST select the first locator. The "p" bit MUST NOT be set for
locator-set records sent in Map-Request and Map-Register messages. 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: set when the sender of a Map-Reply has a route to the locator in
the Map-Reply sender's perspective. the locator data record. This receiver may find this useful to
know when determining if the locator is reachable from the
receiver. See also Section 6.4 for another way the R-bit may be
used.
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. Note that the destination RLOC address MAY be
EID-prefix. Note that the destination RLOC address MAY be an an anycast address. A source RLOC can be an anycast address as
anycast address. A source RLOC can be an anycast address as well. well. The source or destination RLOC MUST NOT be the broadcast
The source or destination RLOC MUST NOT be the broadcast address address (255.255.255.255 or any subnet broadcast address known to
(255.255.255.255 or any subnet broadcast address known to the the router), and MUST NOT be a link-local multicast address. The
router), and MUST NOT be a link-local multicast address. The
source RLOC MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The destination RLOC
SHOULD be a multicast address if it is being mapped from a SHOULD be a multicast address if it is being mapped from a
multicast destination EID. multicast destination EID.
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.5. EID-to-RLOC UDP Map-Reply Message 6.1.5. EID-to-RLOC UDP Map-Reply Message
When a Data Probe packet or a Map-Request triggers a Map-Reply to be A Map-Reply returns an EID-prefix with a prefix length that is less
sent, the RLOCs associated with the EID-prefix matched by the EID in than or equal to the EID being requested. The EID being requested is
the original packet destination IP address field will be returned. either from the destination field of an IP header of a Data-Probe or
The RLOCs in the Map-Reply are the globally-routable IP addresses of the EID record of a Map-Request. The RLOCs in the Map-Reply are
the ETR but are not necessarily reachable; separate testing of globally-routable IP addresses of all ETRs for the LISP site. Each
reachability is required. RLOC conveys status reachability but does not convey path
reachability from a requesters perspective. Separate testing of path
reachability is required, See Section 6.3 for details.
Note that a Map-Reply may contain different EID-prefix granularity Note that a Map-Reply may contain different EID-prefix granularity
(prefix + length) than the Map-Request which triggers it. This might (prefix + length) than the Map-Request which triggers it. This might
occur if a Map-Request were for a prefix that had been returned by an occur if a Map-Request were for a prefix that had been returned by an
earlier Map-Reply. In such a case, the requester updates its cache earlier Map-Reply. In such a case, the requester updates its cache
with the new prefix information and granularity. For example, a with the new prefix information and granularity. For example, a
requester with two cached EID-prefixes that are covered by a Map- requester with two cached EID-prefixes that are covered by a Map-
Reply containing one, less-specific prefix, replaces the entry with Reply containing one, less-specific prefix, replaces the entry with
the less-specific EID-prefix. Note that the reverse, replacement of the less-specific EID-prefix. Note that the reverse, replacement of
one less-specific prefix with multiple more-specific prefixes, can one less-specific prefix with multiple more-specific prefixes, can
skipping to change at page 35, line 39 skipping to change at page 36, line 43
count of 3 to be returned with mapping records for EID-prefixes count of 3 to be returned with mapping records for EID-prefixes
10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. 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 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. A negative Map-
Reply is called a Negative Map-Reply. Negative Map-Replies convey Reply is a Map-Reply with an empty locator-set. Negative Map-Replies
special actions by the sender to the ITR or PTR which have solicited convey special actions by the sender to the ITR or PTR which have
the Map-Reply. There are two primary applications for Negative Map- solicited the Map-Reply. There are two primary applications for
Replies. The first is for a Map-Resolver to instruct an ITR or PTR Negative Map-Replies. The first is for a Map-Resolver to instruct an
when a destination is for a LISP site versus a non-LISP site. And ITR or PTR when a destination is for a LISP site versus a non-LISP
the other is to source quench Map-Requests which are sent for non- site. And the other is to source quench Map-Requests which are sent
allocated EIDs. for non-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 one of the ITR-RLOC fields from the Map-Request. The ETR from the one of the ITR-RLOC fields from the Map-Request. The ETR
can choose a locator address from one of the address families it can choose a locator address from one of the address families it
skipping to change at page 38, line 27 skipping to change at page 39, line 27
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
Authentication Code (MAC) algorithm and key value used for the Authentication Code (MAC) algorithm and key value used for the
authentication function. authentication function.
Authentication Data Length: The length in bytes of the Authentication Data Length: The length in bytes of the
Authentication Data field that follows this field. The length of Authentication Data field that follows this field. The length of
the the Authentication Data field is dependent on the Message the Authentication Data field is dependent on the Message
Authentication Code (MAC) algorithm used. The length field allows Authentication Code (MAC) algorithm used. The length field allows
a device that doesn't know the MAC algorithm to correctly parse a device that doesn't know the MAC algorithm to correctly parse
the packet. the packet.
Authentication Data: The message digest used from the output of the Authentication Data: The message digest used from the output of the
Message Authentication Code (MAC) algorithm. The entire Map- Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0. Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field. After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
is recommended. is recommended.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. However, the record TTL field is not used and set Map-Reply section.
to 0.
6.1.7. Encapsulated 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 48 skipping to change at page 40, line 48
and what follows is either an IPv4 or IPv6 header as encoded by and what follows is either an IPv4 or IPv6 header as encoded by
the first 4 bits after the reserved field. the first 4 bits after the reserved field.
IH: The inner IPv4 or IPv6 header which can use either RLOC or EID IH: The inner IPv4 or IPv6 header which can use either RLOC or EID
addresses in the header address fields. When a Map-Request is addresses in the header address fields. When a Map-Request is
encapsulated in this packet format the destination address in this encapsulated in this packet format the destination address in this
header is an EID. header is an EID.
UDP: The inner UDP header where the port assignments depends on the UDP: The inner UDP header where the port assignments depends on the
control packet being encapsulated. When the control packet is a control packet being encapsulated. When the control packet is a
Map-Request or Map-Register, the source port is randomly assigned Map-Request or Map-Register, the source port is ITR/PITR selected
and the destination port is 4342. When the control packet is a and the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is Map-Reply, the source port is 4342 and the destination port is
assigned from the source port of the invoking Map-Request. Port assigned from the source port of the invoking Map-Request. Port
number 4341 MUST NOT be assigned to either port. The checksum number 4341 MUST NOT be assigned to either port. The checksum
field MUST be non-zero. field MUST be non-zero.
LCM: The format is one of the control message formats described in LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages and PIM this section. At this time, only Map-Request messages and PIM
Join-Prune messages [MLISP] are allowed to be encapsulated. Join-Prune messages [MLISP] are allowed to be encapsulated.
Encapsulating other types of LISP control messages are for further Encapsulating other types of LISP control messages are for further
skipping to change at page 41, line 30 skipping to change at page 42, line 30
this "verifying Map-Request" is used to fully populate the map- this "verifying Map-Request" is used to fully populate the map-
cache entry for the "gleaned" EID and is stored and used for the cache entry for the "gleaned" EID and is stored and used for the
time indicated from the TTL field of a received Map-Reply. When a time indicated from the TTL field of a received Map-Reply. When a
verified map-cache entry is stored, data gleaning no longer occurs verified map-cache entry is stored, data gleaning no longer occurs
for subsequent packets which have a source EID that matches the for subsequent packets which have a source EID that matches the
EID-prefix of the verified entry. EID-prefix of the verified entry.
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
reachable when the R-bit for the locator record is set to 1. Neither reachable when the R-bit for the locator record is set to 1. Neither
the information contained in a Map-Reply or that stored in the the information contained in a Map-Reply or that stored in the
mapping database system provide reachability information for RLOCs. mapping database system provides reachability information for RLOCs.
Such reachability needs to be determined separately, using one or Note that reachability is not part of the mapping system and is
more of the Routing Locator Reachability Algorithms described in the determined using one or more of the Routing Locator Reachability
next section. Algorithms described in the next section.
6.3. Routing Locator Reachability 6.3. Routing Locator Reachability
Several mechanisms for determining RLOC reachability are currently Several mechanisms for determining RLOC reachability are currently
defined: defined:
1. An ETR may examine the Loc-Status-Bits in the LISP header of an 1. An ETR may examine the Loc-Status-Bits in the LISP header of an
encapsulated data packet received from an ITR. If the ETR is encapsulated data packet received from an ITR. If the ETR is
also acting as an ITR and has traffic to return to the original also acting as an ITR and has traffic to return to the original
ITR site, it can use this status information to help select an ITR site, it can use this status information to help select an
skipping to change at page 45, line 30 skipping to change at page 46, line 30
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 probe-bit of the Map-Request and Map-Reply map-cache entry. The probe-bit of the Map-Request and Map-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 may include a mapping data record
record for its own database mapping information. for its own database mapping information which contains the local
EID-prefixes and RLOCs for its site.
When an ETR receives a Map-Request message with the probe-bit set, it When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set from the destination address of the Map-Request the Map-Reply is set from the destination address of the Map-Request
and 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.
skipping to change at page 46, line 9 skipping to change at page 47, line 10
locator. RLOC Probing can also provide rough RTT estimates between a locator. RLOC Probing can also provide rough RTT estimates between a
pair of locators which can be useful for network management purposes pair of locators which can be useful for network management purposes
as 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. EID Reachability within a LISP Site
A site may be multihomed using two or more ETRs. The hosts and
infrastructure within a site will be addressed using one or more EID
prefixes that are mapped to the RLOCs of the relevant ETRs in the
mapping system. One possible failure mode is for an ETR to lose
reachability to one or more of the EID prefixes within its own site.
When this occurs when the ETR sends Map-Replies, it can clear the
R-bit associated with its own locator. And when the ETR is also an
ITR, it can clear its locator-status-bit in the encapsulation data
header.
6.5. 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
a requesting ITR, the locator-set for the EID-prefix may contain a requesting ITR, the locator-set for the EID-prefix may contain
different priority values for each locator address. When more than different priority values for each locator address. When more than
one best priority locator exists, the ITR can decide how to load one best priority locator exists, the ITR can decide how to load
share traffic against the corresponding locators. share traffic against the corresponding locators.
The following hash algorithm may be used by an ITR to select a The following hash algorithm may be used by an ITR to select a
locator for a packet destined to an EID for the EID-to-RLOC mapping: locator for a packet destined to an EID for the EID-to-RLOC mapping:
skipping to change at page 46, line 37 skipping to change at page 47, line 50
compute the hash. compute the hash.
2. Take the hash value and divide it by the number of locators 2. Take the hash value and divide it by the number of locators
stored in the locator-set for the EID-to-RLOC mapping. stored in the locator-set for the EID-to-RLOC mapping.
3. The remainder will be yield a value of 0 to "number of locators 3. The remainder will be yield a value of 0 to "number of locators
minus 1". Use the remainder to select the locator in the minus 1". Use the remainder to select the locator in the
locator-set. locator-set.
Note that when a packet is LISP encapsulated, the source port number Note that when a packet is LISP encapsulated, the source port number
in the outer UDP header needs to be set. Selecting a random value in the outer UDP header needs to be set. Selecting a hashed value
allows core routers which are attached to Link Aggregation Groups allows core routers which are attached to Link Aggregation Groups
(LAGs) to load-split the encapsulated packets across member links of (LAGs) to load-split the encapsulated packets across member links of
such LAGs. Otherwise, core routers would see a single flow, since such LAGs. Otherwise, core routers would see a single flow, since
packets have a source address of the ITR, for packets which are packets have a source address of the ITR, for packets which are
originated by different EIDs at the source site. A suggested setting originated by different EIDs at the source site. A suggested setting
for the source port number computed by an ITR is a 5-tuple hash for the source port number computed by an ITR is a 5-tuple hash
function on the inner header, as described above. function on the inner header, as described above.
Many core router implementations use a 5-tuple hash to decide how to Many core router implementations use a 5-tuple hash to decide how to
balance packet load across members of a LAG. The 5-tuple hash balance packet load across members of a LAG. The 5-tuple hash
includes the source and destination addresses of the packet and the includes the source and destination addresses of the packet and the
source and destination ports when the protocol number in the packet source and destination ports when the protocol number in the packet
is TCP or UDP. For this reason, UDP encoding is used for LISP is TCP or UDP. For this reason, UDP encoding is used for LISP
encapsulation. encapsulation.
6.5. Changing the Contents of EID-to-RLOC Mappings 6.6. Changing the Contents of EID-to-RLOC Mappings
Since the LISP architecture uses a caching scheme to retrieve and Since the LISP architecture uses a caching scheme to retrieve and
store EID-to-RLOC mappings, the only way an ITR can get a more up-to- store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
date mapping is to re-request the mapping. However, the ITRs do not date mapping is to re-request the mapping. However, the ITRs do not
know when the mappings change and the ETRs do not keep track of who know when the mappings change and the ETRs do not keep track of which
requested its mappings. For scalability reasons, we want to maintain ITRs requested its mappings. For scalability reasons, we want to
this approach but need to provide a way for ETRs change their maintain this approach but need to provide a way for ETRs change
mappings and inform the sites that are currently communicating with their mappings and inform the sites that are currently communicating
the ETR site using such mappings. with the ETR site using such mappings.
When a locator record is added to the end of a locator-set, it is When a locator record is added to the end of a locator-set, it is
easy to update mappings. We assume new mappings will maintain the easy to update mappings. We assume new mappings will maintain the
same locator ordering as the old mapping but just have new locators same locator ordering as the old mapping but just have new locators
appended to the end of the list. So some ITRs can have a new mapping appended to the end of the list. So some ITRs can have a new mapping
while other ITRs have only an old mapping that is used until they while other ITRs have only an old mapping that is used until they
time out. When an ITR has only an old mapping but detects bits set time out. When an ITR has only an old mapping but detects bits set
in the loc-status-bits that correspond to locators beyond the list it in the loc-status-bits that correspond to locators beyond the list it
has cached, it simply ignores them. However, this can only happen has cached, it simply ignores them. However, this can only happen
for locator addresses that are lexicographically greater than the for locator addresses that are lexicographically greater than the
skipping to change at page 47, line 46 skipping to change at page 49, line 11
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 three approaches for locator-set compaction, one We propose here three approaches for locator-set compaction, one
operational and two protocol mechanisms. The operational approach operational and two protocol mechanisms. The operational approach
uses a clock sweep method. The protocol approaches use the concept uses a clock sweep method. The protocol approaches use the concept
of Solicit-Map-Requests and Map-Versioning. of Solicit-Map-Requests and Map-Versioning.
6.5.1. Clock Sweep 6.6.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
administrator configures the ETRs at a site to start the clock administrator configures the ETRs at a site to start the clock
sweep window. sweep window.
skipping to change at page 48, line 22 skipping to change at page 49, line 36
3. 24 hours later, all previous cache entries will have timed out, 3. 24 hours later, all previous cache entries will have timed out,
and any active cache entries will time out within 1 hour. During and any active cache entries will time out within 1 hour. During
this 1 hour window the ETRs continue to send Map-Reply messages this 1 hour window the ETRs continue to send Map-Reply messages
with the current (unchanged) mapping records with the TTL set to with the current (unchanged) mapping records with the TTL set to
1 minute. 1 minute.
4. At the end of the 1 hour window, the ETRs will send Map-Reply 4. At the end of the 1 hour window, the ETRs will send Map-Reply
messages with the new (changed) mapping records. So any active messages with the new (changed) mapping records. So any active
caches can get the new mapping contents right away if not cached, caches can get the new mapping contents right away if not cached,
or in 1 minute if they had the mapping cached. or in 1 minute if they had the mapping cached. The new mappings
are cached with a time to live equal to the TTL in the Map-Reply.
6.5.2. Solicit-Map-Request (SMR) 6.6.2. Solicit-Map-Request (SMR)
Soliciting a Map-Request is a selective way for xTRs, at the site Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached. the mappings they have cached.
Since the xTRs don't keep track of remote ITRs that have cached their Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they can not tell exactly who needs the new mapping mappings, they do not know which ITRs need to have their mappings
entries. So an xTR will solicit Map-Requests from sites it is updated. As a result, an ETR will solicit Map-Requests (called an
currently sending encapsulated data to, and only from those sites. SMR message) from those sites to which it has been sending
The xTRs can locally decide the algorithm for how often and to how encapsulated data to for the last minute. In particular, an ETR will
many sites it sends SMR messages. send an SMR an ITR to which it has recently sent encapsulated data.
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. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination.
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 ITR 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 used is the one copied from the SMR message. prefix used is the one copied from the SMR message. If the
source locator is the only locator in the cached locator-set, the
remote ITR SHOULD send a Map-Request to the database mapping
system just in case the single locator has changed and may no
longer be reachable to accept the Map-Request.
3. The remote xTR MUST rate-limit the Map-Request until it gets a 3. The remote ITR 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. When Map
Versioning is used, described in Section 6.6.3, an SMR sender can
detect if an ITR is using the most up to date database 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 that has a nonce from the
nonce matches the nonce from the SMR. The Map-Reply messages SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate
SHOULD be rate limited. This is important to avoid Map-Reply limited. This is important to avoid Map-Reply implosion.
implosion.
5. The ETRs, at the site with the changed mapping, record 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-
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 6.6.3. Database Map Versioning
When there is unidirectional packet flow between an ITR and ETR, and 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 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 ITR so encapsulation can stop to a removed locator and start to a new
locator in the locator-set. locator in the locator-set.
An ETR, when it sends Map-Reply messages, conveys its own Map-Version An ETR, when it sends Map-Reply messages, conveys its own Map-Version
number. This is known as the Destination Map-Version Number. ITRs number. This is known as the Destination Map-Version Number. ITRs
include the Destination Map-Version Number in packets they include the Destination Map-Version Number in packets they
encapsulate to the site. When an ETR decapsulates a packet and encapsulate to the site. When an ETR decapsulates a packet and
detects the Destination Map-Version Number is less than the current detects the Destination Map-Version Number is less than the current
version for its mapping, the SMR procedure described in Section 6.5.2 version for its mapping, the SMR procedure described in Section 6.6.2
occurs. occurs.
An ITR, when it encapsulates packets to ETRs, can convey its own Map- An ITR, when it encapsulates packets to ETRs, can convey its own Map-
Version number. This is known as the Source Map-Version Number. Version number. This is known as the Source Map-Version Number.
When an ETR decapsulates a packet and detects the Source Map-Version 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- 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 Reply from the ITR's site, the ETR will send a Map-Request to one of
the ETRs for the source site. the ETRs for the source site.
A Map-Version Number is used as a sequence number per EID-prefix. So 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 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 of 0 for the Source Map-Version Number or the Destination Map-Version
Number conveys no versioning information and an xTR does no Number conveys no versioning information and an ITR does no
comparison with previously received Map-Version Numbers. comparison with previously received Map-Version Numbers.
A Map-Version Number can be included in Map-Register messages as 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 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. for a site registering to it will be Map-Version number synchronized.
See [VERSIONING] for a more detailed analysis and description of See [VERSIONING] for a more detailed analysis and description of
Database Map Versioning. 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. A
doing tunnel header prepending [RFC1955] and stripping instead of re- few implementation techniques can be used to incrementally implement
writing addresses, existing hardware can support the forwarding model LISP:
with little or no modification. Where modifications are required,
they should be limited to re-programming existing hardware rather
than requiring expensive design changes to hard-coded algorithms in
silicon.
A few implementation techniques can be used to incrementally
implement LISP:
o When a tunnel encapsulated packet is received by an ETR, the outer o When a tunnel encapsulated packet is received by an ETR, the outer
destination address may not be the address of the router. This destination address may not be the address of the router. This
makes it challenging for the control plane to get packets from the makes it challenging for the control plane to get packets from the
hardware. This may be mitigated by creating special FIB entries hardware. This may be mitigated by creating special FIB entries
for the EID-prefixes of EIDs served by the ETR (those for which for the EID-prefixes of EIDs served by the ETR (those for which
the router provides an RLOC translation). These FIB entries are the router provides an RLOC translation). These FIB entries are
marked with a flag indicating that control plane processing should marked with a flag indicating that control plane processing should
be performed. The forwarding logic of testing for particular IP be performed. The forwarding logic of testing for particular IP
protocol number value is not necessary. No changes to existing, protocol number value is not necessary. No changes to existing,
deployed hardware should be needed to support this. deployed hardware should be needed to support this.
o On an ITR, prepending a new IP header is as simple as adding more o On an ITR, prepending a new IP header consists of adding more
bytes to a MAC rewrite string and prepending the string as part of bytes to a MAC rewrite string and prepending the string as part of
the outgoing encapsulation procedure. Many routers that support the outgoing encapsulation procedure. Routers that support GRE
GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
support this action. support this action.
o When a received packet's outer destination address contains an EID o A packet's source address or interface the packet was received on
which is not intended to be forwarded on the routable topology can be used to select a VRF (Virtual Routing/Forwarding). The
(i.e. LISP 1.5), the source address of a data packet or the VRF's routing table can be used to find EID-to-RLOC mappings.
router interface with which the source is associated (the
interface from which it was received) can be associated with a VRF
(Virtual Routing/Forwarding), in which a different (i.e. non-
congruent) topology can be used to find EID-to-RLOC mappings.
8. Deployment Scenarios 8. Deployment Scenarios
This section will explore how and where ITRs and ETRs can be deployed This section will explore how and where ITRs and ETRs can be deployed
and will discuss the pros and cons of each deployment scenario. and will discuss the pros and cons of each deployment scenario.
There are two basic deployment trade-offs to consider: centralized There are two basic deployment trade-offs to consider: centralized
versus distributed caches and flat, recursive, or re-encapsulating versus distributed caches and flat, recursive, or re-encapsulating
tunneling. tunneling.
When deciding on centralized versus distributed caching, the When deciding on centralized versus distributed caching, the
skipping to change at page 52, line 50 skipping to change at page 53, line 50
ISP is doing the TE, then the site has no control. Recursive ISP is doing the TE, then the site has no control. Recursive
tunneling generally will result in suboptimal paths but at the tunneling generally will result in suboptimal paths but at the
benefit of steering traffic to resource available parts of the benefit of steering traffic to resource available parts of the
network. network.
o The technique of re-encapsulation ensures that packets only o The technique of re-encapsulation ensures that packets only
require one tunnel header. So if a packet needs to be rerouted, require one tunnel header. So if a packet needs to be rerouted,
it is first decapsulated by the ETR and then re-encapsulated with it is first decapsulated by the ETR and then re-encapsulated with
a new tunnel header using a new RLOC. a new tunnel header using a new RLOC.
The next sub-sections will describe where tunnel routers can reside The next sub-sections will survey where tunnel routers can reside in
in the network. the network.
8.1. First-hop/Last-hop Tunnel Routers 8.1. First-hop/Last-hop Tunnel Routers
By locating tunnel routers close to hosts, the EID-prefix set is at By locating tunnel routers close to hosts, the EID-prefix set is at
the granularity of an IP subnet. So at the expense of more EID- the granularity of an IP subnet. So at the expense of more EID-
prefix-to-RLOC sets for the site, the caches in each tunnel router prefix-to-RLOC sets for the site, the caches in each tunnel router
can remain relatively small. But caches always depend on the number can remain relatively small. But caches always depend on the number
of non-aggregated EID destination flows active through these tunnel of non-aggregated EID destination flows active through these tunnel
routers. routers.
skipping to change at page 53, line 34 skipping to change at page 54, line 34
LISP functionality can also be deployed in edge switches. These LISP functionality can also be deployed in edge switches. These
devices generally have layer-2 ports facing hosts and layer-3 ports devices generally have layer-2 ports facing hosts and layer-3 ports
facing the Internet. Spare capacity is also often available in these facing the Internet. Spare capacity is also often available in these
devices as well. devices as well.
8.2. Border/Edge Tunnel Routers 8.2. Border/Edge Tunnel Routers
Using customer-edge (CE) routers for tunnel endpoints allows the EID Using customer-edge (CE) routers for tunnel endpoints allows the EID
space associated with a site to be reachable via a small set of RLOCs space associated with a site to be reachable via a small set of RLOCs
assigned to the CE routers for that site. assigned to the CE routers for that site. This is the default
behavior envisioned in the rest of this specification.
This offers the opposite benefit of the first-hop/last-hop tunnel This offers the opposite benefit of the first-hop/last-hop tunnel
router scenario: the number of mapping entries and network management router scenario: the number of mapping entries and network management
touch points are reduced, allowing better scaling. touch points are reduced, allowing better scaling.
One disadvantage is that less of the network's resources are used to One disadvantage is that less of the network's resources are used to
reach host endpoints thereby centralizing the point-of-failure domain reach host endpoints thereby centralizing the point-of-failure domain
and creating network choke points at the CE router. and creating network choke points at the CE router.
Note that more than one CE router at a site can be configured with Note that more than one CE router at a site can be configured with
the same IP address. In this case an RLOC is an anycast address. the same IP address. In this case an RLOC is an anycast address.
This allows resilience between the CE routers. That is, if a CE This allows resilience between the CE routers. That is, if a CE
router fails, traffic is automatically routed to the other routers router fails, traffic is automatically routed to the other routers
using the same anycast address. However, this comes with the using the same anycast address. However, this comes with the
disadvantage where the site cannot control the entrance point when disadvantage where the site cannot control the entrance point when
the anycast route is advertised out from all border routers. the anycast route is advertised out from all border routers. Another
disadvantage of using anycast locators is the limited advertisement
scope of /32 (or /128 for IPv6) routes.
8.3. ISP Provider-Edge (PE) Tunnel Routers 8.3. ISP Provider-Edge (PE) Tunnel Routers
Use of ISP PE routers as tunnel endpoint routers gives an ISP control Use of ISP PE routers as tunnel endpoint routers is not the typical
over the location of the egress tunnel endpoints. That is, the ISP deployment scenario envisioned in the specification. This section
can decide if the tunnel endpoints are in the destination site (in attempts to capture some of reasoning behind this preference of
either CE routers or last-hop routers within a site) or at other PE implementing LISP on CE routers.
edges. The advantage of this case is that two or more tunnel headers
can be avoided. By having the PE be the first router on the path to Use of ISP PE routers as tunnel endpoint routers gives an ISP, rather
encapsulate, it can choose a TE path first, and the ETR can than a site, control over the location of the egress tunnel
decapsulate and re-encapsulate for a tunnel to the destination end endpoints. That is, the ISP can decide if the tunnel endpoints are
site. in the destination site (in either CE routers or last-hop routers
within a site) or at other PE edges. The advantage of this case is
that two tunnel headers can be avoided. By having the PE be the
first router on the path to encapsulate, it can choose a TE path
first, and the ETR can decapsulate and re-encapsulate for a tunnel to
the destination end 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. Other disadvantages
include the difficulty in synchronizing path liveness updates between
CE and PE routers.
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 8.4. LISP Functionality with Conventional NATs
LISP routers can be deployed behind Network Address Translator (NAT) LISP routers can be deployed behind Network Address Translator (NAT)
devices to provide the same set of packet services hosts have today devices to provide the same set of packet services hosts have today
skipping to change at page 62, line 37 skipping to change at page 63, line 37
other Routing Locator address MUST be globally routable. other Routing Locator address MUST be globally routable.
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 host built packet to flow into the core even if
if the source address is allocated out of the EID namespace. If the the source address is allocated out of the EID namespace. If the
RPF-Vector TLV [RFC5496] is used by PIM in the core, then core RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
routers can RPF to the ITR (the Locator address which is injected routers can RPF to the ITR (the Locator address which is injected
into core routing) rather than the host source address (the EID into core routing) rather than the host source address (the EID
address which 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].
skipping to change at page 65, line 5 skipping to change at page 66, line 5
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. IANA Considerations 13. IANA Considerations
This specification has already allocated UDP port numbers 4341 and This specification has already allocated UDP port numbers 4341 and
4342 assigned from the IANA registry. 4342 assigned from the IANA registry.
14. Prototype Plans and Status 14. References
The operator community has requested that the IETF take a practical
approach to solving the scaling problems associated with global
routing state growth. This document offers a simple solution which
is intended for use in a pilot program to gain experience in working
on this problem.
The authors hope that publishing this specification will allow the
rapid implementation of multiple vendor prototypes and deployment on
a small scale. Doing this will help the community:
o Decide whether a new EID-to-RLOC mapping database infrastructure
is needed or if a simple, UDP-based, data-triggered approach is
flexible and robust enough.
o Experiment with provider-independent assignment of EIDs while at
the same time decreasing the size of DFZ routing tables through
the use of topologically-aligned, provider-based RLOCs.
o Determine whether multiple levels of tunneling can be used by ISPs
to achieve their Traffic Engineering goals while simultaneously
removing the more specific routes currently injected into the
global routing system for this purpose.
o Experiment with mobility to determine if both acceptable
convergence and session continuity properties can be scalably
implemented to support both individual device roaming and site
service provider changes.
Here is a rough set of milestones:
1. Interoperable implementations have been available since the
beginning of 2009.
2. Continue pilot deployment using LISP-ALT as the database mapping
mechanism.
3. Continue prototyping and studying other database lookup schemes,
be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms.
4. Implement the LISP Multicast draft [MLISP].
5. Implement the LISP Mobile Node draft [LISP-MN].
6. Research more on how policy affects what gets returned in a Map-
Reply from an ETR.
7. Continue to experiment with mixed locator-sets to understand how
LISP can help the IPv4 to IPv6 transition.
8. Add more robustness to locator reachability between LISP sites.
9. Continue the deployment of Proxy-ETRs (PETRs) for uses like uRPF
avoidance, IPv6 connectivity, and LISP-MN.
As of this writing the following accomplishments have been achieved:
1. A unit- and system-tested software switching implementation has
been completed on cisco NX-OS for this draft for both IPv4 and
IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators.
2. A unit- and system-tested software switching implementation on
cisco NX-OS has been completed for draft [ALT].
3. A unit- and system-tested software switching implementation on
cisco NX-OS has been completed for draft [INTERWORK]. Support
for IPv4 translation is provided and PTR support for IPv4 and
IPv6 is provided.
4. The cisco NX-OS implementation supports an experimental
mechanism for slow mobility.
5. There are 5 LISP implementations that exist and the first 4
below have gone through interoperability testing at IETF
Hiroshima, based on the draft-ietf-lisp-05.txt spec:
1. cisco NX-OS
2. OpenLISP
3. LISP-Click
4. ZLisp
5. cisco IOS
6. Dave Meyer, Vince Fuller, Darrel Lewis, Gregg Schudel, Andrew
Partan and the rest of the lisp-beta team continue to test all
the features described above on a dual-stack infrastructure.
7. Darrel Lewis and Dave Meyer have deployed both LISP translation
and LISP PTR support in the pilot network. Point your browser
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.
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
address-family based locators.
9. An public domain implementation of LISP is available. See
[OPENLISP] for details.
10. We have deployed Map-Resolvers and Map-Servers on the LISP pilot
network to gather experience with [LISP-MS]. The first layer of
the architecture are the xTRs which use Map-Servers for EID-
prefix registration and Map-Resolvers for EID-to-RLOC mapping
resolution. The second layer are the Map-Resolvers and Map-
Servers which connect to the ALT BGP peering infrastructure.
And the third layer are ALT-routers which aggregate EID-prefixes
and forward Map-Requests.
11. A cisco IOS implementation is available which currently supports
IPv4 and IPv6 encapsulation and decapsulation features.
12. A LISP router based LIG implementation is supported, deployed,
and used daily to debug and test the LISP pilot network. See
[LIG] for details.
13. A Linux implementation of LIG has been made available and
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]
for details. Public domain code can be downloaded from
http://github.com/davidmeyer/lig/tree/master.
14. An experimental implementation has been written for three
locator reachability algorithms. Two are the Echo-Noncing and
RLOC-Probing algorithms which are documented in this
specification. The third is called TCP-counts which will be
documented in future drafts.
15. The LISP pilot network has been converted from using MD5 HMAC
authentication for Map-Register messages to SHA-1 HMAC
authentication. ETRs send with SHA-1 but Map-Servers can
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
LISP implementations, or want to be part of the LISP pilot program,
please contact lisp@ietf.org.
15. References
15.1. Normative References 14.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, [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
November 1990. STD 13, RFC 1034, November 1987.
[RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
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.
[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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(HIP) Architecture", RFC 4423, May 2006. (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 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.
15.2. Informative References 14.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/numbers.html, Febuary 2007. NUMBERS http://www.iana.org/numbers.html, Febuary 2007.
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-04.txt (work in progress), April 2010. draft-ietf-lisp-alt-04.txt (work in progress), April 2010.
[APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
L. Zhang, "APT: A Practical Transit Mapping Service",
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.
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-03.txt (work in progress), draft-meyer-lisp-cons-03.txt (work in progress),
November 2007. November 2007.
[DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
Algorithms for DHTs: Some Open Questions", PDF
file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00.txt (work in progress), draft-curran-lisp-emacs-00.txt (work in progress),
November 2007. November 2007.
[GSE] "GSE - An Alternate Addressing Architecture for IPv6",
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),
March 2010. March 2010.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-farinacci-lisp-lcaf-01.txt (work in Address Format", draft-farinacci-lisp-lcaf-00.txt (work in
progress), April 2010. progress), April 2010.
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-ietf-lisp-lig-00.txt (work in progress), April 2010.
[LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
"Renumbering: Threat or Menace?", Usenix , September 1996. "Renumbering: Threat or Menace?", Usenix , September 1996.
[LISP-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-03.txt (work
in progress), July 2009. in progress), August 2010.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-05.txt (work in progress), April 2010. draft-ietf-lisp-ms-05.txt (work in progress), April 2010.
[LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP1) [Routable ID
Version]",
Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
October 2006.
[LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP2) [DNS-based
Version]",
Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt,
November 2006.
[LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT:
Towards a DHT to map identifiers onto locators",
draft-mathy-lisp-dht-00.txt (work in progress),
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-03.txt (work in progress), draft-ietf-lisp-multicast-03.txt (work in progress),
April 2010. April 2010.
skipping to change at page 73, line 31 skipping to change at page 70, line 31
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, Xu Xiaohu, Dhirendra Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra
Trivedi, Yakov Rekhter, John Scudder, John Drake, and Dimitri Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
Papadimitriou. Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, and Vina
Ermagan.
In particular, we would like to thank Dave Meyer for his clever
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-07.txt B.1. Changes to draft-ietf-lisp-08.txt
o Posted August 2010.
o In section 6.1.6, remove statement about setting TTL to 0 in Map-
Register messages.
o Clarify language in section 6.1.5 about Map-Replying to Data-
Probes or Map-Requests.
o Indicate that outer TTL should only be copied to inner TTL when it
is less than inner TTL.
o Indicate a source-EID for RLOC-probes are encoded with an AFI
value of 0.
o Indicate that SMRs can have a global or per SMR destination rate-
limiter.
o Add clarifications to the SMR procedures.
o Add definitions for "client-side" and 'server-side" terms used in
this specification.
o Clear up language in section 6.4, last paragraph.
o Change ACT of value 0 to "no-action". This is so we can RLOC-
probe a PETR and have it return a Map-Reply with a locator-set of
size 0. The way it is spec'ed the map-cache entry has action
"dropped". Drop-action is set to 3.
o Add statement about normalizing locator weights.
o Clarify R-bit definition in the Map-Reply locator record.
o Add section on EID Reachability within a LISP site.
o Clarify another disadvantage of using anycast locators.
o Reworded Abstract.
o Change section 2.0 Introduction to remove obsolete information
such as the LISP variant definitions.
o Change section 5 title from "Tunneling Details" to "LISP
Encapsulation Details".
o Changes to section 5 to include results of network deployment
experience with MTU. Recommend that implementations use either
the stateful or stateless handling.
o Make clarification wordsmithing to Section 7 and 8.
o Identify that if there is one locator in the locator-set of a map-
cache entry, that an SMR from that locator should be responded to
by sending the the SMR-invoked Map-Request to the database mapping
system rather than to the RLOC itself (which may be unreachable).
o When describing Unicast and Multicast Weights indicate the the
values are relative weights rather than percentages. So it
doesn't imply the sum of all locator weights in the locator-set
need to be 100.
o Do some wordsmithing on copying TTL and TOS fields.
o Numerous wordsmithing changes from Dave Meyer. He fine toothed
combed the spec.
o Removed Section 14 "Prototype Plans and Status". We felt this
type of section is no longer appropriate for a protocol
specification.
o Add clarification text for the IRC description per Damien's
commentary.
o Remove text on copying nonce from SMR to SMR-invoked Map- Request
per Vina's comment about a possible DoS vector.
o Clarify (S/2 + H) in the stateless MTU section.
o Add text to reflect Damien's comment about the description of the
"ITR-RLOC Address" field in the Map-Request. that the list of RLOC
addresses are local addresses of the Map-Requester.
B.2. Changes to draft-ietf-lisp-07.txt
o Posted April 2010. o Posted April 2010.
o Added I-bit to data header so LSB field can also be used as an o Added I-bit to data header so LSB field can also be used as an
Instance ID field. When this occurs, the LSB field is reduced to Instance ID field. When this occurs, the LSB field is reduced to
8-bits (from 32-bits). 8-bits (from 32-bits).
o Added V-bit to the data header so the 24-bit nonce field can also o Added V-bit to the data header so the 24-bit nonce field can also
be used for source and destination version numbers. be used for source and destination version numbers.
skipping to change at page 75, line 28 skipping to change at page 74, line 17
o In section 9.2, add text to describe what the signature of o In section 9.2, add text to describe what the signature of
traceroute packets can look like. traceroute packets can look like.
o Removed references to Data Probe for introductory example. Data- o Removed references to Data Probe for introductory example. Data-
probes are still part of the LISP design but not encouraged. probes are still part of the LISP design but not encouraged.
o Added the definition for "LISP site" to the Definition of Terms" o Added the definition for "LISP site" to the Definition of Terms"
section. section.
B.2. Changes to draft-ietf-lisp-06.txt B.3. Changes to draft-ietf-lisp-06.txt
Editorial based changes: Editorial based changes:
o Posted December 2009. o Posted December 2009.
o Fix typo for flags in LISP data header. Changed from "4" to "5". o Fix typo for flags in LISP data header. Changed from "4" to "5".
o Add text to indicate that Map-Register messages must contain a o Add text to indicate that Map-Register messages must contain a
computed UDP checksum. computed UDP checksum.
skipping to change at page 76, line 37 skipping to change at page 75, line 26
These type of Map-Requests are used as RLOC-probes and are sent These type of Map-Requests are used as RLOC-probes and are sent
directly to locator addresses in the underlying network. directly to locator addresses in the underlying network.
o Add text in section 6.1.5 about returning all EID-prefixes in a o Add text in section 6.1.5 about returning all EID-prefixes in a
Map-Reply sent by an ETR when there are overlapping EID-prefixes Map-Reply sent by an ETR when there are overlapping EID-prefixes
configure. configure.
o Add text in a new subsection of section 6.1.5 about dealing with o Add text in a new subsection of section 6.1.5 about dealing with
Map-Replies with coarse EID-prefixes. Map-Replies with coarse EID-prefixes.
B.3. Changes to draft-ietf-lisp-05.txt B.4. 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 77, line 16 skipping to change at page 76, line 5
o The LISP-CONS authors thought that the Type definitions for CONS o The LISP-CONS authors thought that the Type definitions for CONS
should be removed from this specification. should be removed from this specification.
o Removed nonce from Map-Register message, it wasn't used so no need o Removed nonce from Map-Register message, it wasn't used so no need
for it. for it.
o Clarify what to do for unspecified Action bits for negative Map- o Clarify what to do for unspecified Action bits for negative Map-
Replies. Since No Action is a drop, make value 0 Drop. Replies. Since No Action is a drop, make value 0 Drop.
B.4. Changes to draft-ietf-lisp-04.txt B.5. 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 78, line 45 skipping to change at page 77, line 32
field could be used when N is not 1. field could be used when N is not 1.
o Clarify that when E-bit is 0, the nonce field can be an echoed o Clarify that when E-bit is 0, the nonce field can be an echoed
nonce or a random nonce. Comment from Jesper. nonce or a random nonce. Comment from Jesper.
o Indicate when doing data-gleaning that a verifying Map-Request is o Indicate when doing data-gleaning that a verifying Map-Request is
sent to the source-EID of the gleaned data packet so we can avoid sent to the source-EID of the gleaned data packet so we can avoid
map-cache corruption by a 3rd party. Comment from Pedro. map-cache corruption by a 3rd party. Comment from Pedro.
o Indicate that a verifying Map-Request, for accepting mapping data, o Indicate that a verifying Map-Request, for accepting mapping data,
should be sent over the the ALT (or to the EID). should be sent over the ALT (or to the EID).
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.5. Changes to draft-ietf-lisp-03.txt B.6. 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.6. Changes to draft-ietf-lisp-02.txt B.7. 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 [LISP-MN].
B.7. Changes to draft-ietf-lisp-01.txt B.8. 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.8. Changes to draft-ietf-lisp-00.txt B.9. 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. 153 change blocks. 
827 lines changed or deleted 702 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/