draft-ietf-lisp-rfc6830bis-07.txt   draft-ietf-lisp-rfc6830bis-08.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Standards Track D. Meyer Intended status: Standards Track D. Meyer
Expires: May 15, 2018 D. Lewis Expires: July 13, 2018 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
November 11, 2017 January 9, 2018
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-07 draft-ietf-lisp-rfc6830bis-08
Abstract Abstract
This document describes the data-plane protocol for the Locator/ID This document describes the data-plane protocol for the Locator/ID
Separation Protocol (LISP). LISP defines two namespaces, End-point Separation Protocol (LISP). LISP defines two namespaces, End-point
Identifiers (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and Routing Locators
(RLOCs) that identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. With this, LISP
effectively separates control from data, and allows routers to create effectively separates control from data, and allows routers to create
overlay networks. LISP-capable routers exchange encapsulated packets overlay networks. LISP-capable routers exchange encapsulated packets
according to EID-to-RLOC mappings stored in a local map-cache. The according to EID-to-RLOC mappings stored in a local map-cache.
map-cache is populated by the LISP Control-Plane protocol
[I-D.ietf-lisp-rfc6833bis].
LISP requires no change to either host protocol stacks or to underlay LISP requires no change to either host protocol stacks or to underlay
routers and offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming and mobility,
among other features. among other features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on May 15, 2018. This Internet-Draft will expire on July 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 14 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 15 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 16 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19
7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20
7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21
8. Using Virtualization and Segmentation with LISP . . . . . . . 22 8. Using Virtualization and Segmentation with LISP . . . . . . . 22
9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27
10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 30 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32
13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 34 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 35 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router Performance Considerations . . . . . . . . . . . . . . 35 15. Router Performance Considerations . . . . . . . . . . . . . . 35
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35
16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36
16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36
16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37
17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 38 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38
17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39
17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39
17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40
17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 41 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40
18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40
18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41
18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42
19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43
20. Network Management Considerations . . . . . . . . . . . . . . 44 20. Network Management Considerations . . . . . . . . . . . . . . 43
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44
22.2. Informative References . . . . . . . . . . . . . . . . . 47 22.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50
B.1. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52 B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 51
B.2. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 51
B.3. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 51
B.4. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51
B.5. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 53 B.5. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52
B.6. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 B.6. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52
B.7. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 B.7. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52
B.8. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 B.8. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 B.9. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
(LISP). LISP is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built around the
fundamental idea of separating the topological location of a network fundamental idea of separating the topological location of a network
attachment point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. As a result
LISP creates two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers (EIDs), that are
used to identify end-hosts (e.g., nodes or Virtual Machines) and used to identify end-hosts (e.g., nodes or Virtual Machines) and
routable Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify network
attachment points. LISP then defines functions for mapping between attachment points. LISP then defines functions for mapping between
the two namespaces and for encapsulating traffic originated by the two namespaces and for encapsulating traffic originated by
devices using non-routable EIDs for transport across a network devices using non-routable EIDs for transport across a network
infrastructure that routes and forwards using RLOCs. infrastructure that routes and forwards using RLOCs. LISP
encapsulation uses a dynamic form of tunneling where no static
provisioning is required or necessary.
LISP is an overlay protocol that separates control from data-plane, LISP is an overlay protocol that separates control from data-plane,
this document specifies the data-plane, how LISP-capable routers this document specifies the data-plane, how LISP-capable routers
(Tunnel Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating them to the
appropriate location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped with a cache,
called map-cache, that contains EID-to-RLOC mappings. The map-cache called map-cache, that contains EID-to-RLOC mappings. The map-cache
is populated using the LISP Control-Plane protocol is populated using the LISP Control-Plane protocol
[I-D.ietf-lisp-rfc6833bis]. [I-D.ietf-lisp-rfc6833bis].
LISP does not require changes to either host protocol stack or to LISP does not require changes to either host protocol stack or to
skipping to change at page 4, line 31 skipping to change at page 4, line 33
describes the LISP architecture. describes the LISP architecture.
2. Requirements Notation 2. 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].
3. Definition of Terms 3. Definition of Terms
Provider-Independent (PI) Addresses: PI addresses are an address Address Family Identifier (AFI): AFI is a term used to describe an
block assigned from a pool where blocks are not associated with address encoding in a packet. An address family that pertains to
any particular location in the network (e.g., from a particular the data-plane. See [AFN] and [RFC3232] for details. An AFI
service provider) and are therefore not topologically aggregatable value of 0 used in this specification indicates an unspecified
in the routing system. encoded address where the length of the address is 0 octets
following the 16-bit AFI value of 0.
Provider-Assigned (PA) Addresses: PA addresses are an address block Anycast Address: Anycast Address is a term used in this document to
assigned to a site by each service provider to which a site refer to the same IPv4 or IPv6 address configured and used on
connects. Typically, each block is a sub-block of a service multiple systems at the same time. An EID or RLOC can be an
provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and anycast address in each of their own address spaces.
is aggregated into the larger block before being advertised into
the global Internet. Traditionally, IP multihoming has been
implemented by each multihomed site acquiring its own globally
visible prefix. LISP uses only topologically assigned and
aggregatable address blocks for RLOCs, eliminating this
demonstrably non-scalable practice.
Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 Client-side: Client-side is a term used in this document to indicate
[RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is a connection initiation attempt by an EID. The ITR(s) at the LISP
the output of an EID-to-RLOC mapping lookup. An EID maps to one site are the first to get involved in forwarding a packet from the
or more RLOCs. Typically, RLOCs are numbered from topologically source EID.
aggregatable blocks that are assigned to a site at each point to
which it attaches to the global Internet; where the topology is Data-Probe: A Data-Probe is a LISP-encapsulated data packet where
defined by the connectivity of provider networks, RLOCs can be the inner-header destination address equals the outer-header
thought of as PA addresses. Multiple RLOCs can be assigned to the destination address used to trigger a Map-Reply by a decapsulating
same ETR device or to multiple ETR devices at a site. ETR. In addition, the original packet is decapsulated and
delivered to the destination host if the destination EID is in the
EID-Prefix range configured on the ETR. Otherwise, the packet is
discarded. A Data-Probe is used in some of the mapping database
designs to "probe" or request a Map-Reply from an ETR; in other
cases, Map-Requests are used. See each mapping database design
for details. When using Data-Probes, by sending Map-Requests on
the underlying routing system, EID-Prefixes must be advertised.
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP
packet where the destination address in the "outer" IP header is
one of its own RLOCs. The router strips the "outer" header and
forwards the packet based on the next IP header found. In
general, an ETR receives LISP-encapsulated IP packets from the
Internet on one side and sends decapsulated IP packets to site
end-systems on the other side. ETR functionality does not have to
be limited to a router device. A server host can be the endpoint
of a LISP tunnel as well.
EID-to-RLOC Database: The EID-to-RLOC Database is a global
distributed database that contains all known EID-Prefix-to-RLOC
mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID-Prefixes
"behind" the router. These map to one of the router's own
globally visible IP addresses. Note that there MAY be transient
conditions when the EID-Prefix for the site and Locator-Set for
each EID-Prefix may not be the same on all ETRs. This has no
negative implications, since a partial set of Locators can be
used.
EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally
short-lived, on-demand table in an ITR that stores, tracks, and is
responsible for timing out and otherwise validating EID-to-RLOC
mappings. This cache is distinct from the full "database" of EID-
to-RLOC mappings; it is dynamic, local to the ITR(s), and
relatively small, while the database is distributed, relatively
static, and much more global in scope.
EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are
allocated to a site by an address allocation authority. EID-
Prefixes are associated with a set of RLOC addresses. EID-Prefix
allocations can be broken up into smaller blocks when an RLOC set
is to be associated with the larger EID-Prefix block.
End-System: An end-system is an IPv4 or IPv6 device that originates
packets with a single IPv4 or IPv6 header. The end-system
supplies an EID value for the destination address field of the IP
header when communicating globally (i.e., outside of its routing
domain). An end-system can be a host computer, a switch or router
device, or any network appliance.
Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for
IPv6) value used in the source and destination address fields of IPv6) value used in the source and destination address fields of
the first (most inner) LISP header of a packet. The host obtains the first (most inner) LISP header of a packet. The host obtains
a destination EID the same way it obtains a destination address a destination EID the same way it obtains a destination address
today, for example, through a Domain Name System (DNS) [RFC1034] today, for example, through a Domain Name System (DNS) [RFC1034]
lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
The source EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID used on the public Internet host's "local" IP address. An EID used on the public Internet
must have the same properties as any other IP address used in that must have the same properties as any other IP address used in that
manner; this means, among other things, that it must be globally manner; this means, among other things, that it must be globally
unique. An EID is allocated to a host from an EID-Prefix block unique. An EID is allocated to a host from an EID-Prefix block
associated with the site where the host is located. An EID can be associated with the site where the host is located. An EID can be
used by a host to refer to other hosts. Note that EID blocks MAY used by a host to refer to other hosts. Note that EID blocks MAY
be assigned in a hierarchical manner, independent of the network be 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. In theory, the bit is not visible to the global routing system. In theory, the bit
string that represents an EID for one device can represent an RLOC string that represents an EID for one device can represent an RLOC
for a different device. As the architecture is realized, if a for a different device. When used in discussions with other
given bit string is both an RLOC and an EID, it must refer to the
same entity in both cases. When used in discussions with other
Locator/ID separation proposals, a LISP EID will be called an Locator/ID separation proposals, a LISP EID will be called an
"LEID". Throughout this document, any references to "EID" refer "LEID". Throughout this document, any references to "EID" refer
to an LEID. to an LEID.
EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are
allocated to a site by an address allocation authority. EID-
Prefixes are associated with a set of RLOC addresses that make up
a "database mapping". EID-Prefix allocations can be broken up
into smaller blocks when an RLOC set is to be associated with the
larger EID-Prefix block. A globally routed address block (whether
PI or PA) is not inherently an EID-Prefix. A globally routed
address block MAY be used by its assignee as an EID block. The
converse is not supported. That is, a site that receives an
explicitly allocated EID-Prefix may not use that EID-Prefix as a
globally routed prefix. This would require coordination and
cooperation with the entities managing the mapping infrastructure.
Once this has been done, that block could be removed from the
globally routed IP system, if other suitable transition and access
mechanisms are in place. Discussion of such transition and access
mechanisms can be found in [RFC6832] and [RFC7215].
End-system: An end-system is an IPv4 or IPv6 device that originates
packets with a single IPv4 or IPv6 header. The end-system
supplies an EID value for the destination address field of the IP
header when communicating globally (i.e., outside of its routing
domain). An end-system can be a host computer, a switch or router
device, or any network appliance.
Ingress Tunnel Router (ITR): An ITR is a router that resides in a Ingress Tunnel Router (ITR): An ITR is a router that resides in a
LISP site. Packets sent by sources inside of the LISP site to LISP site. Packets sent by sources inside of the LISP site to
destinations outside of the site are candidates for encapsulation destinations outside of the site are candidates for encapsulation
by the ITR. The ITR treats the IP destination address as an EID by the ITR. The ITR treats the IP destination address as an EID
and performs an EID-to-RLOC mapping lookup. The router then and performs an EID-to-RLOC mapping lookup. The router then
prepends an "outer" IP header with one of its routable RLOCs (in prepends an "outer" IP header with one of its routable RLOCs (in
the RLOC space) in the source address field and the result of the the RLOC space) in the source address field and the result of the
mapping lookup in the destination address field. Note that this mapping lookup in the destination address field. Note that this
destination RLOC MAY be an intermediate, proxy device that has destination RLOC MAY be an intermediate, proxy device that has
better knowledge of the EID-to-RLOC mapping closer to the better knowledge of the EID-to-RLOC mapping closer to the
skipping to change at page 6, line 33 skipping to change at page 7, line 5
end-systems on one side and sends LISP-encapsulated IP packets end-systems on one side and sends LISP-encapsulated IP packets
toward the Internet on the other side. 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 host's RLOC) or the inner destination address (the originating host's
supplied EID). supplied EID).
TE-ITR: A TE-ITR is an ITR that is deployed in a service provider LISP Header: LISP header is a term used in this document to refer
network that prepends an additional LISP header for Traffic to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
Engineering purposes. specific 8-octet header that follow the UDP header and that an ITR
prepends or an ETR strips.
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP
packet where the destination address in the "outer" IP header is
one of its own RLOCs. The router strips the "outer" header and
forwards the packet based on the next IP header found. In
general, an ETR receives LISP-encapsulated IP packets from the
Internet on one side and sends decapsulated IP packets to site
end-systems on the other side. ETR functionality does not have to
be limited to a router device. A server host can be the endpoint
of a LISP tunnel as well.
TE-ETR: A TE-ETR is an ETR that is deployed in a service provider
network that strips an outer LISP header for Traffic Engineering
purposes.
xTR: An xTR is a reference to an ITR or ETR when direction of data
flow is not part of the context description. "xTR" refers to the
router that is the tunnel endpoint and is used synonymously with
the term "Tunnel Router". For example, "An xTR can be located at
the Customer Edge (CE) router" indicates both ITR and ETR
functionality at the CE router.
Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling
occurs when an RTR (Re-encapsulating Tunnel Router) acts like an
ETR to remove a LISP header, then acts as an ITR to prepend a new
LISP header. Doing this allows a packet to be re-routed by the
RTR without adding the overhead of additional tunnel headers. Any
references to tunnels in this specification refer to dynamic
encapsulating tunnels; they are never statically configured. When
using multiple mapping database systems, care must be taken to not
create re-encapsulation loops through misconfiguration.
LISP Router: A LISP router is a router that performs the functions LISP Router: A LISP router is a router that performs the functions
of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR),
or Proxy-ETR (PETR). or Proxy-ETR (PETR).
EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally LISP Site: LISP site is a set of routers in an edge network that are
short-lived, on-demand table in an ITR that stores, tracks, and is under a single technical administration. LISP routers that reside
responsible for timing out and otherwise validating EID-to-RLOC in the edge network are the demarcation points to separate the
mappings. This cache is distinct from the full "database" of EID- edge network from the core network.
to-RLOC mappings; it is dynamic, local to the ITR(s), and
relatively small, while the database is distributed, relatively
static, and much more global in scope.
EID-to-RLOC Database: The EID-to-RLOC Database is a global
distributed database that contains all known EID-Prefix-to-RLOC
mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID-Prefixes
"behind" the router. These map to one of the router's own
globally visible IP addresses. Note that there MAY be transient
conditions when the EID-Prefix for the site and Locator-Set for
each EID-Prefix may not be the same on all ETRs. This has no
negative implications, since a partial set of Locators can be
used.
Recursive Tunneling: Recursive Tunneling occurs when a packet has
more than one LISP IP header. Additional layers of tunneling MAY
be employed to implement Traffic Engineering or other re-routing
as needed. When this is done, an additional "outer" LISP header
is added, and the original RLOCs are preserved in the "inner"
header. Any references to tunnels in this specification refer to
dynamic encapsulating tunnels; they are never statically
configured.
LISP Header: LISP header is a term used in this document to refer
to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
specific 8-octet header that follow the UDP header and that an ITR
prepends or an ETR strips.
Address Family Identifier (AFI): AFI is a term used to describe an Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the
address encoding in a packet. An address family that pertains to LISP header. They are used by ITRs to inform ETRs about the up/
the data-plane. See [AFN] and [RFC3232] for details. An AFI down status of all ETRs at the local site. These bits are used as
value of 0 used in this specification indicates an unspecified a hint to convey up/down router status and not path reachability
encoded address where the length of the address is 0 octets status. The LSBs can be verified by use of one of the Locator
following the 16-bit AFI value of 0. reachability algorithms described in Section 10.
Negative Mapping Entry: A negative mapping entry, also known as a Negative Mapping Entry: A negative mapping entry, also known as a
negative cache entry, is an EID-to-RLOC entry where an EID-Prefix negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
is advertised or stored with no RLOCs. That is, the Locator-Set is advertised or stored with no RLOCs. That is, the Locator-Set
for the EID-to-RLOC entry is empty or has an encoded Locator count for the EID-to-RLOC entry is empty or has an encoded Locator count
of 0. This type of entry could be used to describe a prefix from of 0. This type of entry could be used to describe a prefix from
a non-LISP site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the mapping database.
There are a set of well-defined actions that are encoded in a There are a set of well-defined actions that are encoded in a
Negative Map-Reply. Negative Map-Reply.
Data-Probe: A Data-Probe is a LISP-encapsulated data packet where Provider-Assigned (PA) Addresses: PA addresses are an address block
the inner-header destination address equals the outer-header assigned to a site by each service provider to which a site
destination address used to trigger a Map-Reply by a decapsulating connects. Typically, each block is a sub-block of a service
ETR. In addition, the original packet is decapsulated and provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
delivered to the destination host if the destination EID is in the is aggregated into the larger block before being advertised into
EID-Prefix range configured on the ETR. Otherwise, the packet is the underlay network. Traditionally, IP multihoming has been
discarded. A Data-Probe is used in some of the mapping database implemented by each multihomed site acquiring its own globally
designs to "probe" or request a Map-Reply from an ETR; in other visible prefix.
cases, Map-Requests are used. See each mapping database design
for details. When using Data-Probes, by sending Map-Requests on
the underlying routing system, EID-Prefixes must be advertised.
However, this is discouraged if the core is to scale by having
less EID-Prefixes stored in the core router's routing tables.
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A Provider-Independent (PI) Addresses: PI addresses are an address
PITR acts like an ITR but does so on behalf of non-LISP sites that block assigned from a pool where blocks are not associated with
send packets to destinations at LISP sites. any particular location in the network (e.g., from a particular
service provider) and are therefore not topologically aggregatable
in the routing system.
Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A
PETR acts like an ETR but does so on behalf of LISP sites that PETR acts like an ETR but does so on behalf of LISP sites that
send packets to destinations at non-LISP sites. send packets to destinations at non-LISP sites.
Route-returnability: Route-returnability is an assumption that the Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A
PITR acts like an ITR but does so on behalf of non-LISP sites that
send packets to destinations at LISP sites.
Recursive Tunneling: Recursive Tunneling occurs when a packet has
more than one LISP IP header. Additional layers of tunneling MAY
be employed to implement Traffic Engineering or other re-routing
as needed. When this is done, an additional "outer" LISP header
is added, and the original RLOCs are preserved in the "inner"
header.
Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to
remove a LISP header, then acts as an ITR to prepend a new LISP
header. This is known as Re-encapsulating Tunneling. Doing this
allows a packet to be re-routed by the RTR without adding the
overhead of additional tunnel headers. Any references to tunnels
in this specification refer to dynamic encapsulating tunnels; they
are never statically configured. When using multiple mapping
database systems, care must be taken to not create re-
encapsulation loops through misconfiguration.
Route-Returnability: Route-returnability is an assumption that the
underlying routing system will deliver packets to the destination. underlying routing system will deliver packets to the destination.
When combined with a nonce that is provided by a sender and When combined with a nonce that is provided by a sender and
returned by a receiver, this limits off-path data insertion. A returned by a receiver, this limits off-path data insertion. A
route-returnability check is verified when a message is sent with route-returnability check is verified when a message is sent with
a nonce, another message is returned with the same nonce, and the a nonce, another message is returned with the same nonce, and the
destination of the original message appears as the source of the destination of the original message appears as the source of the
returned message. returned message.
LISP site: LISP site is a set of routers in an edge network that are Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6
under a single technical administration. LISP routers that reside [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is
in the edge network are the demarcation points to separate the the output of an EID-to-RLOC mapping lookup. An EID maps to one
edge network from the core network. or more RLOCs. Typically, RLOCs are numbered from aggregatable
blocks that are assigned to a site at each point to which it
Client-side: Client-side is a term used in this document to indicate attaches to the underlay network; where the topology is defined by
a connection initiation attempt by an EID. The ITR(s) at the LISP the connectivity of provider networks. Multiple RLOCs can be
site are the first to get involved in obtaining database Map-Cache assigned to the same ETR device or to multiple ETR devices at a
entries by sending Map-Request messages. site.
Server-side: Server-side is a term used in this document to indicate Server-side: Server-side is a term used in this document to indicate
that a connection initiation attempt is being accepted for a that a connection initiation attempt is being accepted for a
destination EID. The ETR(s) at the destination LISP site may be destination EID.
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.
Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the TE-ETR: A TE-ETR is an ETR that is deployed in a service provider
LISP header. They are used by ITRs to inform ETRs about the up/ network that strips an outer LISP header for Traffic Engineering
down status of all ETRs at the local site. These bits are used as purposes.
a hint to convey up/down router status and not path reachability
status. The LSBs can be verified by use of one of the Locator
reachability algorithms described in Section 10.
Anycast Address: Anycast Address is a term used in this document to TE-ITR: A TE-ITR is an ITR that is deployed in a service provider
refer to the same IPv4 or IPv6 address configured and used on network that prepends an additional LISP header for Traffic
multiple systems at the same time. An EID or RLOC can be an Engineering purposes.
anycast address in each of their own address spaces.
xTR: An xTR is a reference to an ITR or ETR when direction of data
flow is not part of the context description. "xTR" refers to the
router that is the tunnel endpoint and is used synonymously with
the term "Tunnel Router". For example, "An xTR can be located at
the Customer Edge (CE) router" indicates both ITR and ETR
functionality at the CE router.
4. Basic Overview 4. Basic Overview
One key concept of LISP is that end-systems operate the same way they One key concept of LISP is that end-systems operate the same way they
do today. The IP addresses that hosts use for tracking sockets and do today. The IP addresses that hosts use for tracking sockets and
connections, and for sending and receiving packets, do not change. connections, and for sending and receiving packets, do not change.
In LISP terminology, these IP addresses are called Endpoint 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
skipping to change at page 10, line 38 skipping to change at page 10, line 15
o Other types of EID are supported by LISP, see [RFC8060] for o Other types of EID are supported by LISP, see [RFC8060] for
further information. further information.
o LISP routers mostly deal with Routing Locator addresses. See o LISP routers mostly deal with Routing Locator addresses. See
details in Section 4.1 to clarify what is meant by "mostly". details in Section 4.1 to clarify what is meant by "mostly".
o RLOCs are always IP addresses assigned to routers, preferably o RLOCs are always IP addresses assigned to routers, preferably
topologically oriented addresses from provider CIDR (Classless topologically oriented addresses from provider CIDR (Classless
Inter-Domain Routing) blocks. Inter-Domain Routing) blocks.
o When a router originates packets, it may use as a source address o When a router originates packets, it MAY use as a source address
either an EID or RLOC. When acting as a host (e.g., when either an EID or RLOC. When acting as a host (e.g., when
terminating a transport session such as Secure SHell (SSH), terminating a transport session such as Secure SHell (SSH),
TELNET, or the Simple Network Management Protocol (SNMP)), it may TELNET, or the Simple Network Management Protocol (SNMP)), it MAY
use an EID that is explicitly assigned for that purpose. An EID use an EID that is explicitly assigned for that purpose. An EID
that identifies the router as a host MUST NOT be used as an RLOC; that identifies the router as a host MUST NOT be used as an RLOC;
an EID is only routable within the scope of a site. A typical BGP an EID is only routable within the scope of a site. A typical BGP
configuration might demonstrate this "hybrid" EID/RLOC usage where configuration might demonstrate this "hybrid" EID/RLOC usage where
a router could use its "host-like" EID to terminate iBGP sessions a router could use its "host-like" EID to terminate iBGP sessions
to other routers in a site while at the same time using RLOCs to to other routers in a site while at the same time using RLOCs to
terminate eBGP sessions to routers outside the site. terminate eBGP sessions to routers outside the site.
o Packets with EIDs in them are not expected to be delivered end-to- o Packets with EIDs in them are not expected to be delivered end-to-
end in the absence of an EID-to-RLOC mapping operation. They are end in the absence of an EID-to-RLOC mapping operation. They are
expected to be used locally for intra-site communication or to be expected to be used locally for intra-site communication or to be
encapsulated for inter-site communication. encapsulated for inter-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
that is optimized for administrative convenience and to facilitate that is optimized for administrative convenience and to facilitate
scaling of the EID-to-RLOC mapping database. The hierarchy is scaling of the EID-to-RLOC mapping database.
based on an address allocation hierarchy that is 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 (AS). local routing within an Autonomous System (AS).
An additional LISP header MAY be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets by a TE-ITR
when re-routing of the path for a packet is desired. A potential when re-routing of the path for a packet is desired. A potential
use-case for this would be an ISP router that needs to perform use-case for this would be an ISP router that needs to perform
Traffic Engineering for packets flowing through its network. In such Traffic Engineering for packets flowing through its network. In such
a situation, termed "Recursive Tunneling", an ISP transit acts as an a situation, termed "Recursive Tunneling", an ISP transit acts as an
additional ITR, and the RLOC it uses for the new prepended header additional ITR, and the RLOC it uses for the new prepended header
would be either a TE-ETR within the ISP (along an intra-ISP traffic would be either a TE-ETR within the ISP (along an intra-ISP traffic
engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic
skipping to change at page 12, line 17 skipping to change at page 11, line 37
was not using LISP. was not using LISP.
o Each site is multihomed, so each Tunnel Router has an address o Each site is multihomed, 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 the LISP site. located anywhere in the LISP site.
o Map-Requests are sent to the mapping database system by using the o A Map-Request is sent for an external destination when the
LISP control-plane protocol documented in destination is not found in the forwarding table or matches a
[I-D.ietf-lisp-rfc6833bis]. A Map-Request is sent for an external default route. Map-Requests are sent to the mapping database
destination when the destination is not found in the forwarding system by using the LISP control-plane protocol documented in
table or matches a default route. [I-D.ietf-lisp-rfc6833bis].
o Map-Replies are sent on the underlying routing system topology o Map-Replies are sent on the underlying routing system topology
using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol.
Client host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate with server
host2.xyz.example.com: host2.xyz.example.com:
1. host1.abc.example.com wants to open a TCP connection to 1. host1.abc.example.com wants to open a TCP connection to
host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
skipping to change at page 13, line 35 skipping to change at page 13, line 8
of the addresses, strips the LISP header, and forwards packets to of the addresses, strips the LISP header, and forwards packets to
the attached destination host. the attached destination host.
9. In order to defer the need for a mapping lookup in the reverse 9. In order to defer the need for a mapping lookup in the reverse
direction, an ETR can OPTIONALLY create a cache entry that maps direction, an ETR can OPTIONALLY create a cache entry that maps
the source EID (inner-header source IP address) to the source the source EID (inner-header source IP address) to the source
RLOC (outer-header source IP address) in a received LISP packet. RLOC (outer-header source IP address) in a received LISP packet.
Such a cache entry is termed a "gleaned" mapping and only Such a cache entry is termed a "gleaned" mapping and only
contains a single RLOC for the EID in question. More complete contains a single RLOC for the EID in question. More complete
information about additional RLOCs SHOULD be verified by sending information about additional RLOCs SHOULD be verified by sending
a LISP Map-Request for that EID. Both the ITR and the ETR may a LISP Map-Request for that EID. Both the ITR and the ETR MAY
also influence the decision the other makes in selecting an RLOC. also influence the decision the other makes in selecting an RLOC.
5. LISP Encapsulation Details 5. LISP Encapsulation Details
Since additional tunnel headers are prepended, the packet becomes Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed from the ITR to
the ETR. It is RECOMMENDED in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do not get
fragmented as they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. Instead, the packet
is dropped and an ICMP Unreachable/Fragmentation-Needed message is is dropped and an ICMP Unreachable/Fragmentation-Needed message is
returned to the source. returned to the source.
This specification RECOMMENDS that implementations provide support In the case when fragmentation is needed, this specification
for one of the proposed fragmentation and reassembly schemes. Two RECOMMENDS that implementations provide support for one of the
existing schemes are detailed in Section 7. proposed fragmentation and reassembly schemes. Two existing schemes
are detailed in Section 7.
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in IPv4 packet
format). The next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet formats for the
homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4
combinations MUST be supported. Additional types of EIDs are defined combinations MUST be supported. Additional types of EIDs are defined
in [RFC8060]. in [RFC8060].
skipping to change at page 14, line 16 skipping to change at page 14, line 4
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in IPv4 packet
format). The next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet formats for the
homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4
combinations MUST be supported. Additional types of EIDs are defined combinations MUST be supported. Additional types of EIDs are defined
in [RFC8060]. in [RFC8060].
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 | DSCP |ECN| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OH | Time to Live | Protocol = 17 | Header Checksum | OH | Time to Live | Protocol = 17 | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Routing Locator | | | Source Routing Locator |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination Routing Locator | \ | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|R|K|K| Nonce/Map-Version | L |N|L|E|V|I|R|K|K| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL | DSCP |ECN| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH | Time to Live | Protocol | Header Checksum | IH | Time to Live | Protocol | Header Checksum |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source EID | | | Source EID |
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | Destination EID | \ | Destination EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IHL = IP-Header-Length IHL = IP-Header-Length
5.2. LISP IPv6-in-IPv6 Header Format 5.2. LISP IPv6-in-IPv6 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| Traffic Class | Flow Label | / |Version| DSCP |ECN| Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Payload Length | Next Header=17| Hop Limit | | | Payload Length | Next Header=17| Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
O + + O + +
u | | u | |
t + Source Routing Locator + t + Source Routing Locator +
e | | e | |
r + + r + +
| | | |
skipping to change at page 15, line 38 skipping to change at page 15, line 23
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4341 | / | Source Port = xxxx | Dest Port = 4341 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L |N|L|E|V|I|R|K|K| Nonce/Map-Version | L |N|L|E|V|I|R|K|K| Nonce/Map-Version |
I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S / | Instance ID/Locator-Status-Bits | S / | Instance ID/Locator-Status-Bits |
P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| Traffic Class | Flow Label | / |Version| DSCP |ECN| Flow Label |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Payload Length | Next Header | Hop Limit | / | Payload Length | Next Header | Hop Limit |
v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
I + + I + +
n | | n | |
n + Source EID + n + Source EID +
e | | e | |
r + + r + +
| | | |
skipping to change at page 16, line 4 skipping to change at page 15, line 38
I + + I + +
n | | n | |
n + Source EID + n + Source EID +
e | | e | |
r + + r + +
| | | |
H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
d | | d | |
r + + r + +
| | | |
^ + Destination EID + ^ + Destination EID +
\ | | \ | |
\ + + \ + +
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Tunnel Header Field Descriptions 5.3. Tunnel Header Field Descriptions
Inner Header (IH): The inner header is the header on the datagram Inner Header (IH): The inner header is the header on the
received from the originating host. The source and destination IP datagram received from the originating host [RFC0791] [RFC8200]
addresses are EIDs [RFC0791] [RFC8200]. [RFC2474]. The source and destination IP addresses are EIDs.
Outer Header: (OH) The outer header is a new header prepended by an Outer Header: (OH) The outer header is a new header prepended by an
ITR. The address fields contain RLOCs obtained from the ingress ITR. The address fields contain RLOCs obtained from the ingress
router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)"
from [RFC0768]. The setting of the Don't Fragment (DF) bit from [RFC0768]. The setting of the Don't Fragment (DF) bit
'Flags' field is according to rules listed in Sections 7.1 and 'Flags' field is according to rules listed in Sections 7.1 and
7.2. 7.2.
UDP Header: The UDP header contains an ITR selected source port when UDP Header: The UDP header contains an ITR selected source port when
encapsulating a packet. See Section 12 for details on the hash encapsulating a packet. See Section 12 for details on the hash
algorithm used to select a source port based on the 5-tuple of the algorithm used to select a source port based on the 5-tuple of the
inner header. The destination port MUST be set to the well-known inner header. The destination port MUST be set to the well-known
IANA-assigned port value 4341. IANA-assigned port value 4341.
UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero
by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
[RFC6935] [RFC6936]. When a packet with a zero UDP checksum is [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is
received by an ETR, the ETR MUST accept the packet for received by an ETR, the ETR MUST accept the packet for
decapsulation. When an ITR transmits a non-zero value for the UDP decapsulation. When an ITR transmits a non-zero value for the UDP
checksum, it MUST send a correctly computed value in this field. checksum, it MUST send a correctly computed value in this field.
When an ETR receives a packet with a non-zero UDP checksum, it MAY When an ETR receives a packet with a non-zero UDP checksum, it MAY
choose to verify the checksum value. If it chooses to perform choose to verify the checksum value. If it chooses to perform
such verification, and the verification fails, the packet MUST be such verification, and the verification fails, the packet MUST be
silently dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to perform the
verification, or performs the verification successfully, the verification, or performs the verification successfully, the
packet MUST be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The handling of UDP
skipping to change at page 19, line 43 skipping to change at page 19, line 27
Copying the Time to Live (TTL) serves two purposes: first, it Copying the Time to Live (TTL) serves two purposes: first, it
preserves the distance the host intended the packet to travel; preserves the distance the host intended the packet to travel;
second, and more importantly, it provides for suppression of looping second, and more importantly, it provides for suppression of looping
packets in the event there is a loop of concatenated tunnels due to packets in the event there is a loop of concatenated tunnels due to
misconfiguration. See Section 18.3 for TTL exception handling for misconfiguration. See Section 18.3 for TTL exception handling for
traceroute packets. traceroute packets.
The Explicit Congestion Notification ('ECN') field occupies bits 6 The Explicit Congestion Notification ('ECN') field occupies bits 6
and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic
Class' field [RFC3168]. The 'ECN' field requires special treatment Class' field [RFC3168]. The 'ECN' field requires special treatment
in order to avoid discarding indications of congestion [RFC3168]. in order to avoid discarding indications of congestion [RFC3168]. An
ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
header to the outer header. Re-encapsulation MUST copy the 2-bit header to the outer header. Re-encapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the new outer header. 'ECN' field from the stripped outer header to the new outer header.
If the 'ECN' field contains a congestion indication codepoint (the If the 'ECN' field contains a congestion indication codepoint (the
value is '11', the Congestion Experienced (CE) codepoint), then ETR value is '11', the Congestion Experienced (CE) codepoint), then ETR/
decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped
header to the surviving inner header that is used to forward the outer header to the surviving inner header that is used to forward
packet beyond the ETR. These requirements preserve CE indications the packet beyond the ETR. These requirements preserve CE
when a packet that uses ECN traverses a LISP tunnel and becomes indications when a packet that uses ECN traverses a LISP tunnel and
marked with a CE indication due to congestion between the tunnel becomes marked with a CE indication due to congestion between the
endpoints. tunnel endpoints.
6. LISP EID-to-RLOC Map-Cache 6. LISP EID-to-RLOC Map-Cache
ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to-
RLOC Map-Cache, that contains mappings from EID-prefixes to locator RLOC Map-Cache, that contains mappings from EID-prefixes to locator
sets. The cache is used to encapsulate packets from the EID space to sets. The cache is used to encapsulate packets from the EID space to
the corresponding RLOC network attachment point. the corresponding RLOC network attachment point.
When an ITR/PITR receives a packet from inside of the LISP site to When an ITR/PITR receives a packet from inside of the LISP site to
destinations outside of the site a longest-prefix match lookup of the destinations outside of the site a longest-prefix match lookup of the
skipping to change at page 20, line 40 skipping to change at page 20, line 27
information about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP reachability
information mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability of RLOCs, see
Section 10 for the specific mechanisms. Section 10 for the specific mechanisms.
7. Dealing with Large Encapsulated Packets 7. Dealing with Large Encapsulated Packets
This section proposes two mechanisms to deal with packets that exceed This section proposes two mechanisms to deal with packets that exceed
the path MTU between the ITR and ETR. the path MTU between the ITR and ETR.
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 used, since mechanism SHOULD be implemented. Both or neither can be used, since
it is a local decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to deal with MTU
issues, and sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing mechanisms.
Both stateless and stateful mechanisms also apply to Re-encapsulating Both stateless and stateful mechanisms also apply to Re-encapsulating
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 a TE-ITR. also apply to a TE-ITR.
7.1. A Stateless Solution to MTU Handling 7.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
skipping to change at page 21, line 19 skipping to change at page 20, line 49
1. Define H to be the size, in octets, of the outer header an ITR 1. Define H to be the size, in octets, of the outer header an ITR
prepends to a packet. This includes the UDP and LISP header prepends to a packet. This includes the UDP and LISP header
lengths. lengths.
2. Define L to be the size, in octets, of the maximum-sized packet 2. Define L to be the size, in octets, of the maximum-sized packet
an ITR can send to an ETR without the need for the ITR or any an ITR can send to an ETR without the need for the ITR or any
intermediate routers to fragment the packet. intermediate routers to fragment the packet.
3. Define an architectural constant S for the maximum size of a 3. Define an architectural constant S for the maximum size of a
packet, in octets, an ITR must receive from the source so the packet, in octets, an ITR MUST receive from the source so the
effective MTU can be met. That is, L = S + H. effective MTU can be met. That is, L = S + H.
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
octets worth of encapsulation to yield a packet size greater than L octets worth of encapsulation to yield a packet size greater than L
octets (meaning the received packet size was greater than S octets octets (meaning the received packet size was greater than S octets
from the source), it resolves the MTU issue by first splitting the from the source), it resolves the MTU issue by first splitting the
original packet into 2 equal-sized fragments. A LISP header is then original packet into 2 equal-sized fragments. A LISP header is then
prepended to each fragment. The size of the encapsulated fragments prepended to each fragment. The size of the encapsulated fragments
is then (S/2 + H), which is less than the ITR's estimate of the path is then (S/2 + H), which is less than the ITR's estimate of the path
MTU between the ITR and its correspondent ETR. MTU between the ITR and its correspondent ETR.
skipping to change at page 23, line 14 skipping to change at page 22, line 43
When an ETR decapsulates 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.
For example, an 802.1Q VLAN tag or VPN identifier could be used as a For example, an 802.1Q VLAN tag or VPN identifier could be used as a
24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case
details. details.
The Instance ID that is stored in the mapping database when LISP-DDT The Instance ID that is stored in the mapping database when LISP-DDT
[I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the [RFC8111] is used is 32 bits in length. That means the control-plane
control-plane can store more instances than a given data-plane can can store more instances than a given data-plane can use. Multiple
use. Multiple data-planes can use the same 32-bit space as long as data-planes can use the same 32-bit space as long as the low-order 24
the low-order 24 bits don't overlap among xTRs. bits don't overlap among xTRs.
9. Routing Locator Selection 9. Routing Locator Selection
Both the client-side and server-side may need control over the Both the client-side and server-side MAY need control over the
selection of RLOCs for conversations between them. This control is selection of RLOCs for conversations between them. This control is
achieved by manipulating the 'Priority' and 'Weight' fields in EID- achieved by manipulating the 'Priority' and 'Weight' fields in EID-
to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be
gleaned from received tunneled packets or EID-to-RLOC Map-Request gleaned from received tunneled packets or EID-to-RLOC Map-Request
messages. messages.
The following are different scenarios for choosing RLOCs and the The following are different scenarios for choosing RLOCs and the
controls that are available: controls that are available:
o The server-side returns one RLOC. The client-side can only use o The server-side returns one RLOC. The client-side can only use
skipping to change at page 24, line 48 skipping to change at page 24, line 34
stored in the mapping database system provides reachability stored in the mapping database system provides reachability
information for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not part of the
mapping system and is determined using one or more of the Routing mapping system and is determined using one or more of the Routing
Locator reachability algorithms described in the next section. Locator reachability algorithms described in the next section.
10. Routing Locator Reachability 10. 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 Locator-Status-Bits in the LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of
an encapsulated data packet received from an ITR. If the ETR is an 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
RLOC. RLOC.
2. An ITR may receive an ICMP Network Unreachable or Host 2. An ITR MAY receive an ICMP Network Unreachable or Host
Unreachable message for an RLOC it is using. This indicates that Unreachable message for an RLOC it is using. This indicates that
the RLOC is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP messages may
not be desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them completely.
Implementations are encouraged to follow current best practices Implementations are encouraged to follow current best practices
in treating these conditions. in treating these conditions.
3. An ITR that participates in the global routing system can 3. An ITR that participates in the global routing system can
determine that an RLOC is down if no BGP Routing Information Base determine that an RLOC is down if no BGP Routing Information Base
(RIB) route exists that matches the RLOC IP address. (RIB) route exists that matches the RLOC IP address.
4. An ITR may receive an ICMP Port Unreachable message from a 4. An ITR MAY receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use destination host. This occurs if an ITR attempts to use
interworking [RFC6832] and LISP-encapsulated data is sent to a interworking [RFC6832] and LISP-encapsulated data is sent to a
non-LISP-capable site. non-LISP-capable site.
5. An ITR may receive a Map-Reply from an ETR in response to a 5. An ITR MAY receive a Map-Reply from an ETR in response to a
previously sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of the Map-Reply is
likely up, since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the Map-Reply to the
ITR. ITR.
6. When an ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from an ITR, the
source RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet is likely up.
7. An ITR/ETR pair can use the Locator reachability algorithms 7. An ITR/ETR pair can use the Locator reachability algorithms
described in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or RLOC-Probing.
skipping to change at page 26, line 17 skipping to change at page 26, line 6
When an ETR decapsulates a packet, it will check for any change in When an ETR decapsulates a packet, it will check for any change in
the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the
ETR, if acting also as an ITR, will refrain from encapsulating ETR, if acting also as an ITR, will refrain from encapsulating
packets to an RLOC that is indicated as down. It will only resume packets to an RLOC that is indicated as down. It will only resume
using that RLOC if the corresponding Locator-Status-Bit returns to a using that RLOC if the corresponding Locator-Status-Bit returns to a
value of 1. Locator-Status-Bits are associated with a Locator-Set value of 1. Locator-Status-Bits are associated with a Locator-Set
per EID-Prefix. Therefore, when a Locator becomes unreachable, the per EID-Prefix. Therefore, when a Locator becomes unreachable, the
Locator-Status-Bit that corresponds to that Locator's position in the Locator-Status-Bit that corresponds to that Locator's position in the
list returned by the last Map-Reply will be set to zero for that list returned by the last Map-Reply will be set to zero for that
particular EID-Prefix. particular EID-Prefix. Refer to Section 19 for security related
issues regarding Locator-Status-Bits.
When ITRs at the site are not deployed in CE routers, the IGP can When ITRs at the site are not deployed in CE routers, the IGP can
still be used to determine the reachability of Locators, provided still be used to determine the reachability of Locators, provided
they are injected into the IGP. This is typically done when a /32 they are injected into the IGP. This is typically done when a /32
address is configured on a loopback interface. address is configured on a loopback interface.
When ITRs receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host Unreachable
messages as a method to determine unreachability, they will refrain messages as a method to determine unreachability, they will refrain
from using Locators that are described in Locator lists of Map- from using Locators that are described in Locator lists of Map-
Replies. However, using this approach is unreliable because many Replies. However, using this approach is unreliable because many
skipping to change at page 27, line 45 skipping to change at page 27, line 36
E-bit cleared. The ITR sees this "echoed nonce" and knows that the E-bit cleared. The ITR sees this "echoed nonce" and knows that the
path to and from the ETR is up. path to and from the ETR is up.
The ITR will set the E-bit and N-bit for every packet it sends while The ITR will set the E-bit and N-bit for every packet it sends while
in the echo-nonce-request state. The time the ITR waits to process in the echo-nonce-request state. The time the ITR waits to process
the echoed nonce before it determines the path is unreachable is the echoed nonce before it determines the path is unreachable is
variable and is a choice left for the implementation. variable and is a choice left for the implementation.
If the ITR is receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does not see the
nonce echoed while being in the echo-nonce-request state, then the nonce echoed while being in the echo-nonce-request state, then the
path to the ETR is unreachable. This decision may be overridden by path to the ETR is unreachable. This decision MAY be overridden by
other Locator reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR determines that
the path to the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another Locator for
that EID-Prefix. that EID-Prefix.
Note that "ITR" and "ETR" are relative terms here. Both devices MUST Note that "ITR" and "ETR" are relative terms here. Both devices MUST
be implementing both ITR and ETR functionality for the echo nonce be implementing both ITR and ETR functionality for the echo nonce
mechanism to operate. mechanism to operate.
The ITR and ETR may both go into the echo-nonce-request state at the The ITR and ETR MAY both go into the echo-nonce-request state at the
same time. The number of packets sent or the time during which echo same time. The number of packets sent or the time during which echo
nonce requests are sent is an implementation-specific setting. nonce requests are sent is an implementation-specific setting.
However, when an ITR is in the echo-nonce-request state, it can echo However, when an ITR is in the echo-nonce-request state, it can echo
the ETR's nonce in the next set of packets that it encapsulates and the ETR's nonce in the next set of packets that it encapsulates and
subsequently continue sending echo-nonce-request packets. subsequently continue sending echo-nonce-request packets.
This mechanism does not completely solve the forward path This mechanism does not completely solve the forward path
reachability problem, as traffic may be unidirectional. That is, the reachability problem, as traffic may be unidirectional. That is, the
ETR receiving traffic at a site may not be the same device as an ITR ETR receiving traffic at a site MAY not be the same device as an ITR
that transmits traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the site-to-site traffic is
unidirectional so there is no ITR returning traffic. unidirectional so there is no ITR returning traffic.
The echo-nonce algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if one side sets the
E-bit and the other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for echo-noncing, then the
echoing of the nonce does not occur and the requesting side may echoing of the nonce does not occur and the requesting side may
erroneously consider the Locator unreachable. An ITR SHOULD only set erroneously consider the Locator unreachable. An ITR SHOULD only set
the E-bit in an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it knows the ETR is
enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- enabled for echo-noncing. This is conveyed by the E-bit in the RLOC-
probe Map-Reply message. probe Map-Reply message.
Note that other Locator reachability mechanisms are being researched Note other Locator Reachability mechanisms can be used to compliment
and can be used to compliment or even override the echo nonce or even override the echo nonce algorithm. See the next section for
algorithm. See the next section for an example of control-plane an example of control-plane probing.
probing.
10.2. RLOC-Probing Algorithm 10.2. RLOC-Probing Algorithm
RLOC-Probing is a method that an ITR or PITR can use to determine the RLOC-Probing is a method that an ITR or PITR can use to determine the
reachability status of one or more Locators that it has cached in a reachability status of one or more Locators that it has cached in a
Map-Cache entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request and Map-Reply
messages is used for RLOC-Probing. messages is 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 PITR will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to a locator
address from one of its own locator addresses. A Map-Request used as address 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 to an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to
the mapping database system as one would when soliciting mapping the mapping database system as one would when soliciting mapping
data. The EID record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is the EID-Prefix of
the Map-Cache entry cached by the ITR or PITR. The ITR may include a the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data record for its own database mapping information that mapping data record for its own database mapping information that
contains the local EID-Prefixes and RLOCs for its site. RLOC-probes contains the local EID-Prefixes and RLOCs for its site. RLOC-probes
are sent periodically using a jittered timer interval. are sent periodically using a jittered timer interval.
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 according to the procedure described in the Map-Reply is set according to the procedure described in
[I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping [I-D.ietf-lisp-rfc6833bis]. 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 PITR that sent the RLOC-probe to get the opportunity for the ITR or PITR that sent the RLOC-probe to get
skipping to change at page 29, line 27 skipping to change at page 29, line 14
reachable or has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a robust
mechanism for switching to using another Locator from the cached mechanism for switching to using another Locator from the cached
Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT)
estimates between a pair of Locators, which can be useful for network estimates between a pair of Locators, which can be useful for network
management purposes as well as for selecting low delay paths. The management purposes as well as for selecting low delay paths. The
major disadvantage of RLOC-Probing is in the number of control major disadvantage of RLOC-Probing is in the number of control
messages required and the amount of bandwidth used to obtain those messages required and the amount of bandwidth used to obtain those
benefits, especially if the requirement for failure detection times benefits, especially if the requirement for failure detection times
is very small. is very small.
Continued research and testing will attempt to characterize the
tradeoffs of failure detection times versus message overhead.
11. EID Reachability within a LISP Site 11. EID Reachability within a LISP Site
A site may be multihomed using two or more ETRs. The hosts and 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- 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 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 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. 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 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 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 ITR, it can clear its Locator-Status-Bit in the encapsulation data
header. header.
It is recognized that there are no simple solutions to the site It is recognized that there are no simple solutions to the site
partitioning problem because it is hard to know which part of the partitioning problem because it is hard to know which part of the
EID-Prefix range is partitioned and which Locators can reach any sub- EID-Prefix range is partitioned and which Locators can reach any sub-
ranges of the EID-Prefixes. This problem is under investigation with ranges of the EID-Prefixes. Note that this is not a new problem
the expectation that experiments will tell us more. Note that this introduced by the LISP architecture. The problem exists today when a
is not a new problem introduced by the LISP architecture. The multihomed site uses BGP to advertise its reachability upstream.
problem exists today when a multihomed site uses BGP to advertise its
reachability upstream.
12. Routing Locator Hashing 12. 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
a requesting ITR, the Locator-Set for the EID-Prefix may contain that is stored in the map-cache of a requesting ITR, the Locator-Set
different Priority values for each locator address. When more than for the EID-Prefix MAY contain different Priority and Weight values
one best Priority Locator exists, the ITR can decide how to load- for each locator address. When more than one best Priority Locator
share traffic against the corresponding Locators. exists, the ITR can decide how to load-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:
1. Either a source and destination address hash or the traditional 1. Either a source and destination address hash or the traditional
5-tuple hash can be used. The traditional 5-tuple hash includes 5-tuple hash can be used. The traditional 5-tuple hash includes
the source and destination addresses; source and destination TCP, the source and destination addresses; source and destination TCP,
UDP, or Stream Control Transmission Protocol (SCTP) port numbers; UDP, or Stream Control Transmission Protocol (SCTP) port numbers;
and the IP protocol number field or IPv6 next-protocol fields of and the IP protocol number field or IPv6 next-protocol fields of
a packet that a host originates from within a LISP site. When a a packet that a host originates from within a LISP site. When a
packet is not a TCP, UDP, or SCTP packet, the source and packet is not a TCP, UDP, or SCTP packet, the source and
destination addresses only from the header are used to compute destination addresses only from the header are used to compute
skipping to change at page 34, line 6 skipping to change at page 33, line 30
Replies. To avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a third party, a
sender of an SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. If an ITR
receives an SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is not in the
Locator-Set for the stored Map-Cache entry, then the responding Map- Locator-Set for the stored Map-Cache entry, then the responding Map-
Request MUST be sent with an EID destination to the mapping database Request MUST be sent with an EID destination to the mapping database
system. Since the mapping database system is a more secure way to system. Since the mapping database system is a more secure way to
reach an authoritative ETR, it will deliver the Map-Request to the reach an authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data. authoritative source of the mapping data.
When an ITR receives an SMR-based Map-Request for which it does not When an ITR receives an SMR-based Map-Request for which it does not
have a cached mapping for the EID in the SMR message, it MAY not send have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked Map-Request. This scenario can occur when an ETR an SMR-invoked Map-Request. This scenario can occur when an ETR
sends SMR messages to all Locators in the Locator-Set it has stored sends SMR messages to all Locators in the Locator-Set it has stored
in its map-cache but the remote ITRs that receive the SMR may not be in its map-cache but the remote ITRs that receive the SMR may not be
sending packets to the site. There is no point in updating the ITRs sending packets to the site. There is no point in updating the ITRs
until they need to send, in which case they will send Map-Requests to until they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry. obtain a Map-Cache entry.
13.3. Database Map-Versioning 13.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
skipping to change at page 35, line 52 skipping to change at page 35, line 26
few implementation techniques can be used to incrementally implement few implementation techniques can be used to incrementally implement
LISP: LISP:
o When a tunnel-encapsulated packet is received by an ETR, the outer o When a tunnel-encapsulated packet is received by an ETR, the outer
destination address may not be the address of the router. This destination address may not be the address of the router. This
makes it challenging for the control plane to get packets from the makes it challenging for the control plane to get packets from the
hardware. This may be mitigated by creating special Forwarding hardware. This may be mitigated by creating special Forwarding
Information Base (FIB) entries for the EID-Prefixes of EIDs served Information Base (FIB) entries for the EID-Prefixes of EIDs served
by the ETR (those for which the router provides an RLOC by the ETR (those for which the router provides an RLOC
translation). These FIB entries are marked with a flag indicating translation). These FIB entries are marked with a flag indicating
that control-plane processing should be performed. The forwarding that control-plane processing SHOULD be performed. The forwarding
logic of testing for particular IP protocol number values is not logic of testing for particular IP protocol number values is not
necessary. There are a few proven cases where no changes to necessary. There are a few proven cases where no changes to
existing deployed hardware were needed to support the LISP data- existing deployed hardware were needed to support the LISP data-
plane. plane.
o On an ITR, prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of adding more
octets to a MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the string as part
of the outgoing encapsulation procedure. Routers that support of the outgoing encapsulation procedure. Routers that support
Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4
tunneling [RFC3056] may already support this action. tunneling [RFC3056] may already support this action.
skipping to change at page 38, line 15 skipping to change at page 37, line 40
17. LISP xTR Placement and Encapsulation Methods 17. LISP xTR Placement and Encapsulation Methods
This section will explore how and where ITRs and ETRs can be placed This section will explore how and where ITRs and ETRs can be placed
in the network and will discuss the pros and cons of each scenario. in the network and will discuss the pros and cons of each scenario.
For a more detailed networkd design deployment recommendation, refer For a more detailed networkd design deployment recommendation, refer
to [RFC7215]. to [RFC7215].
There are two basic deployment tradeoffs to consider: centralized There are two basic deployment tradeoffs to consider: centralized
versus distributed caches; and flat, Recursive, or Re-encapsulating versus distributed caches; and flat, Recursive, or Re-encapsulating
Tunneling. When deciding on centralized versus distributed caching, Tunneling. When deciding on centralized versus distributed caching,
the following issues should be considered: the following issues SHOULD be considered:
o Are the xTRs spread out so that the caches are spread across all o Are the xTRs spread out so that the caches are spread across all
the memories of each router? A centralized cache is when an ITR the memories of each router? A centralized cache is when an ITR
keeps a cache for all the EIDs it is encapsulating to. The packet keeps a cache for all the EIDs it is encapsulating to. The packet
takes a direct path to the destination Locator. A distributed takes a direct path to the destination Locator. A distributed
cache is when an ITR needs help from other Re-Encapsulating Tunnel cache is when an ITR needs help from other Re-Encapsulating Tunnel
Routers (RTRs) because it does not store all the cache entries for Routers (RTRs) because it does not store all the cache entries for
the EIDs it is encapsulating to. So, the packet takes a path the EIDs it is encapsulating to. So, the packet takes a path
through RTRs that have a different set of cache entries. through RTRs that have a different set of cache entries.
o Should management "touch points" be minimized by only choosing a o Should management "touch points" be minimized by only choosing a
few xTRs, just enough for redundancy? few xTRs, just enough for redundancy?
o In general, using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase management load,
since caches are built and stored dynamically. On the other hand, since caches are built and stored dynamically. On the other hand,
using more ETRs does require more management, since EID-Prefix-to- using more ETRs does require more management, since EID-Prefix-to-
RLOC mappings need to be explicitly configured. RLOC mappings need to be explicitly configured.
When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the
following issues should be considered: following issues SHOULD be considered:
o Flat tunneling implements a single encapsulation path between the o Flat tunneling implements a single encapsulation path between the
source site and destination site. This generally offers better source site and destination site. This generally offers better
paths between sources and destinations with a single encapsulation paths between sources and destinations with a single encapsulation
path. path.
o Recursive Tunneling is when encapsulated traffic is again further o Recursive Tunneling is when encapsulated traffic is again further
encapsulated in another tunnel, either to implement VPNs or to encapsulated in another tunnel, either to implement VPNs or to
perform Traffic Engineering. When doing VPN-based tunneling, the perform Traffic Engineering. When doing VPN-based tunneling, the
site has some control, since the site is prepending a new site has some control, since the site is prepending a new
encapsulation header. In the case of TE-based tunneling, the site encapsulation header. In the case of TE-based tunneling, the site
may have control if it is prepending a new tunnel header, but if MAY have control if it is prepending a new tunnel header, but if
the site's ISP is doing the TE, then the site has no control. the site's ISP is doing the TE, then the site has no control.
Recursive Tunneling generally will result in suboptimal paths but Recursive Tunneling generally will result in suboptimal paths but
with the benefit of steering traffic to parts of the network that with the benefit of steering traffic to parts of the network that
have more resources available. have more resources available.
o The technique of Re-Encapsulation ensures that packets only o The technique of Re-Encapsulation ensures that packets only
require one encapsulation header. So, if a packet needs to be re- require one encapsulation header. So, if a packet needs to be re-
routed, it is first decapsulated by the RTR and then Re- routed, it is first decapsulated by the RTR and then Re-
Encapsulated with a new encapsulation header using a new RLOC. Encapsulated with a new encapsulation header using a new RLOC.
skipping to change at page 41, line 12 skipping to change at page 40, line 36
addresses MUST be used only in the outer IP header so the NAT device addresses MUST be used only in the outer IP header so the NAT device
can translate properly. Otherwise, EID addresses MUST be translated can translate properly. Otherwise, EID addresses MUST be translated
before encapsulation is performed when LISP VPNs are not in use. before encapsulation is performed when LISP VPNs are not in use.
Both NAT translation and LISP encapsulation functions could be co- Both NAT translation and LISP encapsulation functions could be co-
located in the same device. located in the same device.
17.5. Packets Egressing a LISP Site 17.5. Packets Egressing a LISP Site
When a LISP site is using two ITRs for redundancy, the failure of one When a LISP site is using two ITRs for redundancy, the failure of one
ITR will likely shift outbound traffic to the second. This second ITR will likely shift outbound traffic to the second. This second
ITR's cache may not be populated with the same EID-to-RLOC mapping ITR's cache MAY not be populated with the same EID-to-RLOC mapping
entries as the first. If this second ITR does not have these entries as the first. If this second ITR does not have these
mappings, traffic will be dropped while the mappings are retrieved mappings, traffic will be dropped while the mappings are retrieved
from the mapping system. The retrieval of these messages may from the mapping system. The retrieval of these messages may
increase the load of requests being sent into the mapping system. increase the load of requests being sent into the mapping system.
18. Traceroute Considerations 18. Traceroute Considerations
When a source host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a traceroute to a
destination host in another LISP site, it is highly desirable for it destination host in another LISP site, it is highly desirable for it
to see the entire path. Since packets are encapsulated from the ITR to see the entire path. Since packets are encapsulated from the ITR
skipping to change at page 44, line 16 skipping to change at page 43, line 42
Map-Versioning is a data-plane mechanism used to signal a peering xTR Map-Versioning is a data-plane mechanism used to signal a peering xTR
that a local EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so that the
peering xTR uses LISP Control-Plane signaling message to retrieve a peering xTR uses LISP Control-Plane signaling message to retrieve a
fresh mapping. This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to forge the map-
versioning field of a LISP encapsulated header and force an excessive versioning field of a LISP encapsulated header and force an excessive
amount of signaling between xTRs that may overload them. amount of signaling between xTRs that may overload them.
Most of the attack vectors can be mitigated with careful deployment Most of the attack vectors can be mitigated with careful deployment
and configuration, information learned opportunistically (such as LSB and configuration, information learned opportunistically (such as LSB
or gleaning) should be verified with other reachability mechanisms. or gleaning) SHOULD be verified with other reachability mechanisms.
In addition, systematic rate-limitation and filtering is an effective In addition, systematic rate-limitation and filtering is an effective
technique to mitigate attacks that aim to overload the control-plane. technique to mitigate attacks that aim to overload the control-plane.
20. Network Management Considerations 20. Network Management Considerations
Considerations for network management tools exist so the LISP Considerations for network management tools exist so the LISP
protocol suite can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These mechanisms can be
found in [RFC7052] and [RFC6835]. found in [RFC7052] and [RFC6835].
21. IANA Considerations 21. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
data-plane LISP specification, in accordance with BCP 26 [RFC5226]. data-plane LISP specification, in accordance with BCP 26 [RFC8126].
21.1. LISP UDP Port Numbers 21.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port numbers 4341 and 4342 for The IANA registry has allocated UDP port numbers 4341 and 4342 for
lisp-data and lisp-control operation, respectively. IANA has updated lisp-data and lisp-control operation, respectively. IANA has updated
the description for UDP ports 4341 and 4342 as follows: the description for UDP ports 4341 and 4342 as follows:
lisp-data 4341 udp LISP Data Packets lisp-data 4341 udp LISP Data Packets
lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control Packets
22. References 22. References
22.1. Normative References 22.1. Normative References
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-09 (work in progress), January 2017.
[I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015.
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-06 (work in progress), October draft-ietf-lisp-rfc6833bis-07 (work in progress), December
2017. 2017.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November "Definition of the Differentiated Services Field (DS
1998, <https://www.rfc-editor.org/info/rfc2404>. Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[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, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <https://www.rfc-editor.org/info/rfc3232>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009,
<https://www.rfc-editor.org/info/rfc5496>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010, RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>. <https://www.rfc-editor.org/info/rfc5944>.
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, DOI 10.17487/RFC6115, February 2011,
<https://www.rfc-editor.org/info/rfc6115>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January 2013,
<https://www.rfc-editor.org/info/rfc6834>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052,
DOI 10.17487/RFC7052, October 2013,
<https://www.rfc-editor.org/info/rfc7052>.
[RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated
Channel (G-ACh) IANA Registries to a New Registry",
RFC 7214, DOI 10.17487/RFC7214, May 2014,
<https://www.rfc-editor.org/info/rfc7214>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833, Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016, DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>. <https://www.rfc-editor.org/info/rfc7833>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Separation Protocol (LISP) Threat Analysis", RFC 7835, Writing an IANA Considerations Section in RFCs", BCP 26,
DOI 10.17487/RFC7835, April 2016, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
22.2. Informative References 22.2. Informative References
[AFN] IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August 2016,
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed",
1999, 1999,
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[I-D.ietf-lisp-eid-mobility] [I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-00 Unified Control Plane", draft-ietf-lisp-eid-mobility-01
(work in progress), May 2017. (work in progress), November 2017.
[I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015.
[I-D.ietf-lisp-mn] [I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-01 (work in progress), Mobile Node", draft-ietf-lisp-mn-01 (work in progress),
October 2017. October 2017.
[I-D.ietf-lisp-predictive-rlocs] [I-D.ietf-lisp-predictive-rlocs]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", draft-ietf-lisp-predictive-rlocs-00 (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in
progress), June 2017. progress), November 2017.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017.
[I-D.ietf-lisp-signal-free-multicast] [I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-06 (work in draft-ietf-lisp-signal-free-multicast-07 (work in
progress), August 2017. progress), November 2017.
[I-D.ietf-lisp-vpn] [I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", draft-ietf-lisp-vpn-00 (work in Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in
progress), May 2017. progress), November 2017.
[I-D.meyer-loc-id-implications] [I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01 Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009. (work in progress), January 2009.
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin,
"Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix Tenth System
Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), October 1996.
skipping to change at page 49, line 9 skipping to change at page 47, line 22
[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,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[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, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <https://www.rfc-editor.org/info/rfc3232>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005, DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
[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, Optimization for Mobile IPv6", RFC 4866,
DOI 10.17487/RFC4866, May 2007, DOI 10.17487/RFC4866, May 2007,
<https://www.rfc-editor.org/info/rfc4866>. <https://www.rfc-editor.org/info/rfc4866>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>. <https://www.rfc-editor.org/info/rfc4984>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012,
<https://www.rfc-editor.org/info/rfc6518>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January 2013,
<https://www.rfc-editor.org/info/rfc6834>.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013, DOI 10.17487/RFC6835, January 2013,
<https://www.rfc-editor.org/info/rfc6835>. <https://www.rfc-editor.org/info/rfc6835>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935, UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013, DOI 10.17487/RFC6935, April 2013,
<https://www.rfc-editor.org/info/rfc6935>. <https://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013, RFC 6936, DOI 10.17487/RFC6936, April 2013,
<https://www.rfc-editor.org/info/rfc6936>. <https://www.rfc-editor.org/info/rfc6936>.
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052,
DOI 10.17487/RFC7052, October 2013,
<https://www.rfc-editor.org/info/rfc7052>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>. February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews of the LISP
architecture and documents, coupled with enthusiasm for making LISP a architecture and documents, coupled with enthusiasm for making LISP a
skipping to change at page 52, line 5 skipping to change at page 51, line 5
The LISP working group would like to give a special thanks to Jari The LISP working group would like to give a special thanks to Jari
Arkko, the Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set of LISP
documents were being prepared for IESG last call, and for his documents were being prepared for IESG last call, and for his
meticulous reviews and detailed commentaries on the 7 working group meticulous reviews and detailed commentaries on the 7 working group
last call documents progressing toward standards-track RFCs. last call documents progressing toward standards-track RFCs.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6830bis-06 B.1. Changes to draft-ietf-lisp-rfc6830bis-08
o Posted January 2018.
o Remove references to research work for any protocol mechanisms.
o Document scanned to make sure it is RFC 2119 compliant.
o Made changes to reflect comments from document WG shepherd Luigi
Iannone.
o Ran IDNITs on the document.
B.2. Changes to draft-ietf-lisp-rfc6830bis-07
o Posted November 2017. o Posted November 2017.
o Rephrase how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer to [RFC1918]
addresses. addresses.
B.2. Changes to draft-ietf-lisp-rfc6830bis-06 B.3. Changes to draft-ietf-lisp-rfc6830bis-06
o Posted October 2017. o Posted October 2017.
o Put RTR definition before it is used. o Put RTR definition before it is used.
o Rename references that are now working group drafts. o Rename references that are now working group drafts.
o Remove "EIDs MUST NOT be used as used by a host to refer to other o Remove "EIDs MUST NOT be used as used by a host to refer to other
hosts. Note that EID blocks MAY LISP RLOCs". hosts. Note that EID blocks MAY LISP RLOCs".
skipping to change at page 52, line 35 skipping to change at page 51, line 48
o ETRs may, rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send Map-Replies.
o Recommend, rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation headers to 2.
o Reference VPN draft when introducing Instance-ID. o Reference VPN draft when introducing Instance-ID.
o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Indicate that SMRs can be sent when ITR/ETR are in the same node.
o Clarify when private addreses can be used. o Clarify when private addreses can be used.
B.3. Changes to draft-ietf-lisp-rfc6830bis-05 B.4. Changes to draft-ietf-lisp-rfc6830bis-05
o Posted August 2017. o Posted August 2017.
o Make it clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router is an RTR.
B.4. Changes to draft-ietf-lisp-rfc6830bis-04 B.5. Changes to draft-ietf-lisp-rfc6830bis-04
o Posted July 2017. o Posted July 2017.
o Changed reference of IPv6 RFC2460 to RFC8200. o Changed reference of IPv6 RFC2460 to RFC8200.
o Indicate that the applicability statement for UDP zero checksums o Indicate that the applicability statement for UDP zero checksums
over IPv6 adheres to RFC6936. over IPv6 adheres to RFC6936.
B.5. Changes to draft-ietf-lisp-rfc6830bis-03 B.6. Changes to draft-ietf-lisp-rfc6830bis-03
o Posted May 2017. o Posted May 2017.
o Move the control-plane related codepoints in the IANA o Move the control-plane related codepoints in the IANA
Considerations section to RFC6833bis. Considerations section to RFC6833bis.
B.6. Changes to draft-ietf-lisp-rfc6830bis-02 B.7. Changes to draft-ietf-lisp-rfc6830bis-02
o Posted April 2017. o Posted April 2017.
o Reflect some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien Sausez.
B.7. Changes to draft-ietf-lisp-rfc6830bis-01 B.8. Changes to draft-ietf-lisp-rfc6830bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Change references from RFC6833 to RFC6833bis. o Change references from RFC6833 to RFC6833bis.
o Clarified LCAF text in the IANA section. o Clarified LCAF text in the IANA section.
o Remove references to "experimental". o Remove references to "experimental".
B.8. Changes to draft-ietf-lisp-rfc6830bis-00 B.9. Changes to draft-ietf-lisp-rfc6830bis-00
o Posted December 2016. o Posted December 2016.
o Created working group document from draft-farinacci-lisp o Created working group document from draft-farinacci-lisp
-rfc6830-00 individual submission. No other changes made. -rfc6830-00 individual submission. No other changes made.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: farinacci@gmail.com EMail: farinacci@gmail.com
Vince Fuller Vince Fuller
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: vince.fuller@gmail.com EMail: vince.fuller@gmail.com
Dave Meyer Dave Meyer
Cisco Systems Cisco Systems
 End of changes. 108 change blocks. 
396 lines changed or deleted 340 lines changed or added

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