draft-ietf-lisp-rfc6830bis-05.txt   draft-ietf-lisp-rfc6830bis-06.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: March 2, 2018 D. Lewis Expires: May 3, 2018 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
August 29, 2017 October 30, 2017
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-05 draft-ietf-lisp-rfc6830bis-06
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. The
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 http://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 March 2, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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 . . . . . . . . . . . . . . . . . . . 30
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . 34
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 35
15. Router Performance Considerations . . . . . . . . . . . . . . 35 15. Router Performance Considerations . . . . . . . . . . . . . . 35
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36
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 . . . . . . . . 38
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39
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 . . . . . . . . . . . . . . 40
17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40
skipping to change at page 3, line 22 skipping to change at page 3, line 22
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43
19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43
20. Network Management Considerations . . . . . . . . . . . . . . 44 20. Network Management Considerations . . . . . . . . . . . . . . 44
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 . . . . . . . . . . . . . . . . . 47
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51
B.1. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 B.1. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52
B.2. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 52
B.3. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 B.3. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52
B.4. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 B.4. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52
B.5. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 B.5. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53
B.7. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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. EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY
LISP RLOCs. Note that EID blocks MAY be assigned in a be assigned in a hierarchical manner, independent of the network
hierarchical manner, independent of the network topology, to topology, to facilitate scaling of the mapping database. In
facilitate scaling of the mapping database. In addition, an EID addition, an EID block assigned to a site may have site-local
block assigned to a site may have site-local structure structure (subnetting) for routing within the site; this structure
(subnetting) for routing within the site; this structure is not is not visible to the global routing system. In theory, the bit
visible to the global routing system. In theory, the bit string string that represents an EID for one device can represent an RLOC
that represents an EID for one device can represent an RLOC for a for a different device. As the architecture is realized, if a
different device. As the architecture is realized, if a given bit given bit string is both an RLOC and an EID, it must refer to the
string is both an RLOC and an EID, it must refer to the same same entity in both cases. When used in discussions with other
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 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- allocated to a site by an address allocation authority. EID-
Prefixes are associated with a set of RLOC addresses that make up Prefixes are associated with a set of RLOC addresses that make up
a "database mapping". EID-Prefix allocations can be broken up a "database mapping". EID-Prefix allocations can be broken up
into smaller blocks when an RLOC set is to be associated with the into smaller blocks when an RLOC set is to be associated with the
larger EID-Prefix block. A globally routed address block (whether larger EID-Prefix block. A globally routed address block (whether
skipping to change at page 6, line 17 skipping to change at page 6, line 14
supplies an EID value for the destination address field of the IP supplies an EID value for the destination address field of the IP
header when communicating globally (i.e., outside of its routing header when communicating globally (i.e., outside of its routing
domain). An end-system can be a host computer, a switch or router domain). An end-system can be a host computer, a switch or router
device, or any network appliance. 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 globally routable prepends an "outer" IP header with one of its routable RLOCs (in
RLOCs in the source address field and the result of the mapping the RLOC space) in the source address field and the result of the
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
destination EID. In general, an ITR receives IP packets from site destination EID. In general, an ITR receives IP packets from site
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
skipping to change at page 7, line 9 skipping to change at page 7, line 7
network that strips an outer LISP header for Traffic Engineering network that strips an outer LISP header for Traffic Engineering
purposes. purposes.
xTR: An xTR is a reference to an ITR or ETR when direction of data 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 flow is not part of the context description. "xTR" refers to the
router that is the tunnel endpoint and is used synonymously with router that is the tunnel endpoint and is used synonymously with
the term "Tunnel Router". For example, "An xTR can be located at the term "Tunnel Router". For example, "An xTR can be located at
the Customer Edge (CE) router" indicates both ITR and ETR the Customer Edge (CE) router" indicates both ITR and ETR
functionality at the CE router. 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 a short-lived, EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally
on-demand table in an ITR that stores, tracks, and is responsible short-lived, on-demand table in an ITR that stores, tracks, and is
for timing out and otherwise validating EID-to-RLOC mappings. responsible for timing out and otherwise validating EID-to-RLOC
This cache is distinct from the full "database" of EID-to-RLOC mappings. This cache is distinct from the full "database" of EID-
mappings; it is dynamic, local to the ITR(s), and relatively to-RLOC mappings; it is dynamic, local to the ITR(s), and
small, while the database is distributed, relatively static, and relatively small, while the database is distributed, relatively
much more global in scope. static, and much more global in scope.
EID-to-RLOC Database: The EID-to-RLOC Database is a global EID-to-RLOC Database: The EID-to-RLOC Database is a global
distributed database that contains all known EID-Prefix-to-RLOC distributed database that contains all known EID-Prefix-to-RLOC
mappings. Each potential ETR typically contains a small piece of mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID-Prefixes the database: the EID-to-RLOC mappings for the EID-Prefixes
"behind" the router. These map to one of the router's own "behind" the router. These map to one of the router's own
globally visible IP addresses. The same database mapping entries globally visible IP addresses. Note that there MAY be transient
MUST be configured on all ETRs for a given site. In a steady conditions when the EID-Prefix for the site and Locator-Set for
state, the EID-Prefixes for the site and the Locator-Set for each each EID-Prefix may not be the same on all ETRs. This has no
EID-Prefix MUST be the same on all ETRs. Procedures to enforce negative implications, since a partial set of Locators can be
and/or verify this are outside the scope of this document. Note used.
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 Recursive Tunneling: Recursive Tunneling occurs when a packet has
more than one LISP IP header. Additional layers of tunneling MAY more than one LISP IP header. Additional layers of tunneling MAY
be employed to implement Traffic Engineering or other re-routing be employed to implement Traffic Engineering or other re-routing
as needed. When this is done, an additional "outer" LISP header as needed. When this is done, an additional "outer" LISP header
is added, and the original RLOCs are preserved in the "inner" is added, and the original RLOCs are preserved in the "inner"
header. Any references to tunnels in this specification refer to header. Any references to tunnels in this specification refer to
dynamic encapsulating tunnels; they are never statically dynamic encapsulating tunnels; they are never statically
configured. configured.
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 Header: LISP header is a term used in this document to refer 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- 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 specific 8-octet header that follow the UDP header and that an ITR
prepends or an ETR strips. prepends or an ETR strips.
Address Family Identifier (AFI): AFI is a term used to describe an Address Family Identifier (AFI): AFI is a term used to describe an
address encoding in a packet. An address family currently address encoding in a packet. An address family that pertains to
pertains to an IPv4 or IPv6 address. See [AFN] and [RFC3232] for the data-plane. See [AFN] and [RFC3232] for details. An AFI
details. An AFI value of 0 used in this specification indicates value of 0 used in this specification indicates an unspecified
an unspecified encoded address where the length of the address is encoded address where the length of the address is 0 octets
0 octets following the 16-bit AFI value of 0. following the 16-bit AFI value of 0.
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.
skipping to change at page 9, line 24 skipping to change at page 9, line 19
in the edge network are the demarcation points to separate the in the edge network are the demarcation points to separate the
edge network from the core network. edge network from the core network.
Client-side: Client-side is a term used in this document to indicate Client-side: Client-side is a term used in this document to indicate
a connection initiation attempt by an EID. The ITR(s) at the LISP a connection initiation attempt by an EID. The ITR(s) at the LISP
site are the first to get involved in obtaining database Map-Cache site are the first to get involved in obtaining database Map-Cache
entries by sending Map-Request messages. entries by sending Map-Request messages.
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 are the destination EID. The ETR(s) at the destination LISP site may be
first to send Map-Replies to the source site initiating the the first to send Map-Replies to the source site initiating the
connection. The ETR(s) at this destination site can obtain connection. The ETR(s) at this destination site can obtain
mappings by gleaning information from Map-Requests, Data-Probes, mappings by gleaning information from Map-Requests, Data-Probes,
or encapsulated packets. or encapsulated packets.
Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the
LISP header. They are used by ITRs to inform ETRs about the up/ LISP header. They are used by ITRs to inform ETRs about the up/
down status of all ETRs at the local site. These bits are used as down status of all ETRs at the local site. These bits are used as
a hint to convey up/down router status and not path reachability 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 status. The LSBs can be verified by use of one of the Locator
reachability algorithms described in Section 10. reachability algorithms described in Section 10.
skipping to change at page 11, line 30 skipping to change at page 11, line 27
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
engineered path, where an agreement to build such a path exists). engineered path, where an agreement to build such a path exists).
In order to avoid excessive packet overhead as well as possible In order to avoid excessive packet overhead as well as possible
encapsulation loops, this document mandates that a maximum of two encapsulation loops, this document recommends that a maximum of two
LISP headers can be prepended to a packet. For initial LISP LISP headers can be prepended to a packet. For initial LISP
deployments, it is assumed that two headers is sufficient, where the deployments, it is assumed that two headers is sufficient, where the
first prepended header is used at a site for Location/Identity first prepended header is used at a site for Location/Identity
separation and the second prepended header is used inside a service separation and the second prepended header is used inside a service
provider for Traffic Engineering purposes. provider for Traffic Engineering purposes.
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
For example, the ITR for a particular end-to-end packet exchange For example, the ITR for a particular end-to-end packet exchange
might be the first-hop or default router within a site for the source might be the first-hop or default router within a site for the source
host. Similarly, the ETR might be the last-hop router directly host. Similarly, the ETR might be the last-hop router directly
skipping to change at page 23, line 10 skipping to change at page 23, line 10
that prepends a LISP header will copy a 24-bit value used by the LISP that prepends a LISP header will copy a 24-bit value used by the LISP
router to uniquely identify the address space. The value is copied router to uniquely identify the address space. The value is copied
to the 'Instance ID' field of the LISP header, and the I-bit is set to the 'Instance ID' field of the LISP header, and the I-bit is set
to 1. to 1.
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. 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case
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 [I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the
control-plane can store more instances than a given data-plane can control-plane can store more instances than a given data-plane can
use. Multiple data-planes can use the same 32-bit space as long as use. Multiple data-planes can use the same 32-bit space as long as
the low-order 24 bits don't overlap among xTRs. the low-order 24 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
skipping to change at page 28, line 27 skipping to change at page 28, line 27
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 Map- enabled for echo-noncing. This is conveyed by the E-bit in the RLOC-
Reply message. probe Map-Reply message.
Note that other Locator reachability mechanisms are being researched Note that other Locator reachability mechanisms are being researched
and can be used to compliment or even override the echo nonce and can be used to compliment or even override the echo nonce
algorithm. See the next section for an example of control-plane algorithm. See the next section for 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
skipping to change at page 31, line 11 skipping to change at page 31, line 11
source and destination ports when the protocol number in the packet source and destination ports when the protocol number in the packet
is TCP or UDP. For this reason, UDP encoding is used for LISP is TCP or UDP. For this reason, UDP encoding is used for LISP
encapsulation. encapsulation.
13. Changing the Contents of EID-to-RLOC Mappings 13. Changing the Contents of EID-to-RLOC Mappings
Since the LISP architecture uses a caching scheme to retrieve and Since the LISP architecture uses a caching scheme to retrieve and
store EID-to-RLOC mappings, the only way an ITR can get a more up-to- store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
date mapping is to re-request the mapping. However, the ITRs do not date mapping is to re-request the mapping. However, the ITRs do not
know when the mappings change, and the ETRs do not keep track of know when the mappings change, and the ETRs do not keep track of
which ITRs requested its mappings. For scalability reasons, we want which ITRs requested its mappings. For scalability reasons, it is
to maintain this approach but need to provide a way for ETRs to desirable to maintain this approach but need to provide a way for
change their mappings and inform the sites that are currently ETRs to change their mappings and inform the sites that are currently
communicating with the ETR site using such mappings. communicating with the ETR site using such mappings.
When adding a new Locator record in lexicographic order to the end of When adding a new Locator record in lexicographic order to the end of
a Locator-Set, it is easy to update mappings. We assume that new a Locator-Set, it is easy to update mappings. We assume that new
mappings will maintain the same Locator ordering as the old mapping mappings will maintain the same Locator ordering as the old mapping
but will just have new Locators appended to the end of the list. So, but will just have new Locators appended to the end of the list. So,
some ITRs can have a new mapping while other ITRs have only an old some ITRs can have a new mapping while other ITRs have only an old
mapping that is used until they time out. When an ITR has only an mapping that is used until they time out. When an ITR has only an
old mapping but detects bits set in the Locator-Status-Bits that old mapping but detects bits set in the Locator-Status-Bits that
correspond to Locators beyond the list it has cached, it simply correspond to Locators beyond the list it has cached, it simply
skipping to change at page 32, line 46 skipping to change at page 32, line 46
where mappings change, to control the rate they receive requests for where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached. the mappings they have cached.
Since the ETRs don't keep track of remote ITRs that have cached their Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending SMR message) from those sites to which it has been sending
encapsulated data for the last minute. In particular, an ETR will encapsulated data for the last minute. In particular, an ETR will
send an SMR to an ITR to which it has recently sent encapsulated send an SMR to an ITR to which it has recently sent encapsulated
data. data. This can only occur when both ITR and ETR functionality reside
in the same router.
An SMR message is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request message. An ITR
or PITR will send a Map-Request when they receive an SMR message. or PITR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder MUST rate-limit Both the SMR sender and the Map-Request responder MUST rate-limit
these messages. Rate-limiting can be implemented as a global rate- these messages. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination. limiter or one rate-limiter per SMR destination.
The following procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange occurs when a site
is doing Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC mapping:
skipping to change at page 36, line 43 skipping to change at page 36, line 47
decoupling the address space used by a site from the address spaces decoupling the address space used by a site from the address spaces
used by its ISPs [RFC4984]. used by its ISPs [RFC4984].
16.2. Fast Mobility 16.2. Fast Mobility
Fast endpoint mobility occurs when an endpoint moves relatively Fast endpoint mobility occurs when an endpoint moves relatively
rapidly, changing its IP-layer network attachment point. Maintenance rapidly, changing its IP-layer network attachment point. Maintenance
of session continuity is a goal. This is where the Mobile IPv4 of session continuity is a goal. This is where the Mobile IPv4
[RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and
primarily where interactions with LISP need to be explored, such as primarily where interactions with LISP need to be explored, such as
the mechanisms in [I-D.portoles-lisp-eid-mobility] when the EID moves the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but
but the RLOC is in the network infrastructure. the RLOC is in the network infrastructure.
In LISP, one possibility is to "glean" information. When a packet In LISP, one possibility is to "glean" information. When a packet
arrives, the ETR could examine the EID-to-RLOC mapping and use that arrives, the ETR could examine the EID-to-RLOC mapping and use that
mapping for all outgoing traffic to that EID. It can do this after mapping for all outgoing traffic to that EID. It can do this after
performing a route-returnability check, to ensure that the new performing a route-returnability check, to ensure that the new
network location does have an internal route to that endpoint. network location does have an internal route to that endpoint.
However, this does not cover the case where an ITR (the node assigned However, this does not cover the case where an ITR (the node assigned
the RLOC) at the mobile-node location has been compromised. the RLOC) at the mobile-node location has been compromised.
Mobile IP packet exchange is designed for an environment in which all Mobile IP packet exchange is designed for an environment in which all
skipping to change at page 37, line 31 skipping to change at page 37, line 36
for any endpoint will return a binding for the entire mobile prefix. for any endpoint will return a binding for the entire mobile prefix.
If mobile networks become a more common occurrence, it may be useful If mobile networks become a more common occurrence, it may be useful
to revisit the design of the mapping service and allow for dynamic to revisit the design of the mapping service and allow for dynamic
updates of the database. updates of the database.
The issue of interactions between mobility and LISP needs to be The issue of interactions between mobility and LISP needs to be
explored further. Specific improvements to the entire system will explored further. Specific improvements to the entire system will
depend on the details of mapping mechanisms. Mapping mechanisms depend on the details of mapping mechanisms. Mapping mechanisms
should be evaluated on how well they support session continuity for should be evaluated on how well they support session continuity for
mobile nodes. See [I-D.farinacci-lisp-predictive-rlocs] for more mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent
recent mechanisms which can provide near-zero packet loss during mechanisms which can provide near-zero packet loss during handoffs.
handoffs.
16.3. LISP Mobile Node Mobility 16.3. LISP Mobile Node Mobility
A mobile device can use the LISP infrastructure to achieve mobility A mobile device can use the LISP infrastructure to achieve mobility
by implementing the LISP encapsulation and decapsulation functions by implementing the LISP encapsulation and decapsulation functions
and acting as a simple ITR/ETR. By doing this, such a "LISP mobile and acting as a simple ITR/ETR. By doing this, such a "LISP mobile
node" can use topologically independent EID IP addresses that are not node" can use topologically independent EID IP addresses that are not
advertised into and do not impose a cost on the global routing advertised into and do not impose a cost on the global routing
system. These EIDs are maintained at the edges of the mapping system system. These EIDs are maintained at the edges of the mapping system
in LISP Map-Servers and Map-Resolvers) and are provided on demand to in LISP Map-Servers and Map-Resolvers) and are provided on demand to
skipping to change at page 40, line 46 skipping to change at page 40, line 46
and provider want control, then Recursive or Re-Encapsulating Tunnels and provider want control, then Recursive or Re-Encapsulating Tunnels
are used. are used.
17.4. LISP Functionality with Conventional NATs 17.4. LISP Functionality with Conventional NATs
LISP routers can be deployed behind Network Address Translator (NAT) LISP routers can be deployed behind Network Address Translator (NAT)
devices to provide the same set of packet services hosts have today devices to provide the same set of packet services hosts have today
when they are addressed out of private address space. when they are addressed out of private address space.
It is important to note that a locator address in any LISP control It is important to note that a locator address in any LISP control
message MUST be a globally routable address and therefore SHOULD NOT message MUST be a routable address and therefore [RFC1918] addresses
contain [RFC1918] addresses. If a LISP xTR is configured with SHOULD only be presence when running in a local environment. When a
private RLOC addresses, they MUST be used only in the outer IP header LISP xTR is configured with private RLOC addresses and resides behind
so the NAT device can translate properly. Otherwise, EID addresses a NAT device and desires to communicate on the Internet, the private
MUST be translated before encapsulation is performed when LISP VPNs addresses MUST be used only in the outer IP header so the NAT device
are not in use. Both NAT translation and LISP encapsulation can translate properly. Otherwise, EID addresses MUST be translated
functions could be co-located in the same device. before encapsulation is performed when LISP VPNs are not in use.
Both NAT translation and LISP encapsulation functions could be co-
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.
skipping to change at page 45, line 14 skipping to change at page 45, line 14
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. 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-05 (work in progress), May draft-ietf-lisp-rfc6833bis-06 (work in progress), October
2017. 2017.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), November 2016. (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, <https://www.rfc- DOI 10.17487/RFC0768, August 1980,
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, <https://www.rfc- DOI 10.17487/RFC0791, September 1981,
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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
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 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[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 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
January 2002, <https://www.rfc-editor.org/info/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, <https://www.rfc- DOI 10.17487/RFC4086, June 2005,
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- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, <https://www.rfc- DOI 10.17487/RFC4868, May 2007,
editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc- DOI 10.17487/RFC5226, May 2008,
editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, Forwarding (RPF) Vector TLV", RFC 5496,
DOI 10.17487/RFC5496, March 2009, <https://www.rfc- DOI 10.17487/RFC5496, March 2009,
editor.org/info/rfc5496>. <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", [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, DOI 10.17487/RFC6115, February 2011, RFC 6115, DOI 10.17487/RFC6115, February 2011,
<https://www.rfc-editor.org/info/rfc6115>. <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 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January 2013, <https://www.rfc- DOI 10.17487/RFC6834, January 2013,
editor.org/info/rfc6834>. <https://www.rfc-editor.org/info/rfc6834>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>. January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
Separation Protocol (LISP) MIB", RFC 7052, Separation Protocol (LISP) MIB", RFC 7052,
DOI 10.17487/RFC7052, October 2013, <https://www.rfc- DOI 10.17487/RFC7052, October 2013,
editor.org/info/rfc7052>. <https://www.rfc-editor.org/info/rfc7052>.
[RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated [RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated
Channel (G-ACh) IANA Registries to a New Registry", Channel (G-ACh) IANA Registries to a New Registry",
RFC 7214, DOI 10.17487/RFC7214, May 2014, RFC 7214, DOI 10.17487/RFC7214, May 2014,
<https://www.rfc-editor.org/info/rfc7214>. <https://www.rfc-editor.org/info/rfc7214>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>. 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, <https://www.rfc- DOI 10.17487/RFC7833, May 2016,
editor.org/info/rfc7833>. <https://www.rfc-editor.org/info/rfc7833>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, <https://www.rfc- DOI 10.17487/RFC7835, April 2016,
editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc7835>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017, <https://www.rfc- DOI 10.17487/RFC8061, February 2017,
editor.org/info/rfc8061>. <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, <https://www.rfc- DOI 10.17487/RFC8200, July 2017,
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.farinacci-lisp-predictive-rlocs] [I-D.ietf-lisp-eid-mobility]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
RLOCs", draft-farinacci-lisp-predictive-rlocs-02 (work in F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
progress), May 2017. Unified Control Plane", draft-ietf-lisp-eid-mobility-00
(work in progress), May 2017.
[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-00 (work in progress), Mobile Node", draft-ietf-lisp-mn-01 (work in progress),
April 2017. October 2017.
[I-D.ietf-lisp-predictive-rlocs]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", draft-ietf-lisp-predictive-rlocs-00 (work in
progress), June 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-06 (work in
progress), August 2017. progress), August 2017.
[I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", draft-ietf-lisp-vpn-00 (work in
progress), May 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.
[I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-02 (work in progress), April 2017.
[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.
[OPENLISP] [OPENLISP]
Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
Implementation Report", Work in Progress, July 2008. Implementation Report", Work in Progress, July 2008.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[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, <https://www.rfc- DOI 10.17487/RFC2784, March 2000,
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>.
[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, <https://www.rfc- DOI 10.17487/RFC3261, June 2002,
editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/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, <https://www.rfc- DOI 10.17487/RFC4192, September 2005,
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, <https://www.rfc- DOI 10.17487/RFC4866, May 2007,
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 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012, <https://www.rfc- DOI 10.17487/RFC6518, February 2012,
editor.org/info/rfc6518>. <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, <https://www.rfc- DOI 10.17487/RFC6832, January 2013,
editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
[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, <https://www.rfc- DOI 10.17487/RFC6835, January 2013,
editor.org/info/rfc6835>. <https://www.rfc-editor.org/info/rfc6835>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013, <https://www.rfc- DOI 10.17487/RFC6837, January 2013,
editor.org/info/rfc6837>. <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, <https://www.rfc- DOI 10.17487/RFC6935, April 2013,
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>.
[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>.
skipping to change at page 52, line 5 skipping to change at page 52, 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-04 B.1. Changes to draft-ietf-lisp-rfc6830bis-06
o Posted October 2017.
o Put RTR definition before it is used.
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
hosts. Note that EID blocks MAY LISP RLOCs".
o Indicate what address-family can appear in data packets.
o ETRs may, rather than will, be the ones to send Map-Replies.
o Recommend, rather than mandate, max encapsulation headers to 2.
o Reference VPN draft when introducing Instance-ID.
o Indicate that SMRs can be sent when ITR/ETR are in the same node.
o Clarify when private addreses can be used.
B.2. Changes to draft-ietf-lisp-rfc6830bis-05
o Posted August 2017.
o Make it clear that a Reencapsulating Tunnel Router is an RTR.
B.3. 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.2. Changes to draft-ietf-lisp-rfc6830bis-03 B.4. 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.3. Changes to draft-ietf-lisp-rfc6830bis-02 B.5. 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.4. Changes to draft-ietf-lisp-rfc6830bis-01 B.6. 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.5. Changes to draft-ietf-lisp-rfc6830bis-00 B.7. 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
 End of changes. 58 change blocks. 
144 lines changed or deleted 179 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/