draft-ietf-lisp-rfc6830bis-08.txt   draft-ietf-lisp-rfc6830bis-09.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: July 13, 2018 D. Lewis Expires: August 17, 2018 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
January 9, 2018 February 13, 2018
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-08 draft-ietf-lisp-rfc6830bis-09
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. according to EID-to-RLOC mappings stored in a local map-cache.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 July 13, 2018. This Internet-Draft will expire on August 17, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 10
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 12
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . 22
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26
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 . . . . . . . . . . . . . 28
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 31
13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router Performance Considerations . . . . . . . . . . . . . . 35 15. Router Performance Considerations . . . . . . . . . . . . . . 34
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35
16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 35
16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 35
16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 36
17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38
17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 38
17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39
17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 39
17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40
18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40
18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41
18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 41
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42
19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 42
20. Network Management Considerations . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 43
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 43
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 43
22.2. Informative References . . . . . . . . . . . . . . . . . 45 22.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 50 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 49
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 50 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 49
B.1. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 51 B.1. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 50
B.2. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 51 B.2. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 50
B.3. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 51 B.3. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 50
B.4. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51 B.4. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 50
B.5. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 B.5. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51
B.6. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 B.6. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 51
B.7. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 B.7. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 51
B.8. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 B.8. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 51
B.9. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 B.9. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 51
B.10. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 4, line 16 skipping to change at page 4, line 17
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
underlay routers. By separating the EID from the RLOC space, LISP underlay routers. By separating the EID from the RLOC space, LISP
offers native Traffic Engineering, multihoming and mobility, among offers native Traffic Engineering, multihoming and mobility, among
other features. other features.
Creation of LISP was initially motivated by discussions during the Creation of LISP was initially motivated by discussions during the
IAB-sponsored Routing and Addressing Workshop held in Amsterdam in IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
October 2006 (see [RFC4984]) October 2006 (see [RFC4984]).
This document specifies the LISP data-plane encapsulation and other This document specifies the LISP data-plane encapsulation and other
LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis]
specifies the LISP control plane. LISP deployment guidelines can be specifies the LISP control plane. LISP deployment guidelines can be
found in [RFC7215] and [RFC6835] describes considerations for network found in [RFC7215] and [RFC6835] describes considerations for network
operational management. Finally, [I-D.ietf-lisp-introduction] operational management. Finally, [I-D.ietf-lisp-introduction]
describes the LISP architecture. describes the LISP architecture.
2. Requirements Notation 2. Requirements Notation
skipping to change at page 4, line 46 skipping to change at page 4, line 47
value of 0 used in this specification indicates an unspecified value of 0 used in this specification indicates an unspecified
encoded address where the length of the address is 0 octets encoded address where the length of the address is 0 octets
following the 16-bit AFI value of 0. following the 16-bit AFI value of 0.
Anycast Address: Anycast Address is a term used in this document to Anycast Address: Anycast Address is a term used in this document to
refer to the same IPv4 or IPv6 address configured and used on refer to the same IPv4 or IPv6 address configured and used on
multiple systems at the same time. An EID or RLOC can be an multiple systems at the same time. An EID or RLOC can be an
anycast address in each of their own address spaces. anycast address in each of their own address spaces.
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 end-system represented by an
site are the first to get involved in forwarding a packet from the EID.
source EID.
Data-Probe: A Data-Probe is a LISP-encapsulated data packet where Data-Probe: A Data-Probe is a LISP-encapsulated data packet where
the inner-header destination address equals the outer-header the inner-header destination address equals the outer-header
destination address used to trigger a Map-Reply by a decapsulating destination address used to trigger a Map-Reply by a decapsulating
ETR. In addition, the original packet is decapsulated and ETR. In addition, the original packet is decapsulated and
delivered to the destination host if the destination EID is in the delivered to the destination host if the destination EID is in the
EID-Prefix range configured on the ETR. Otherwise, the packet is EID-Prefix range configured on the ETR. Otherwise, the packet is
discarded. A Data-Probe is used in some of the mapping database 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 designs to "probe" or request a Map-Reply from an ETR; in other
cases, Map-Requests are used. See each mapping database design cases, Map-Requests are used. See each mapping database design
skipping to change at page 6, line 16 skipping to change at page 6, line 16
device, or any network appliance. 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. When used in discussions with other for a different device. When used in discussions with other
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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.
Provider-Assigned (PA) Addresses: PA addresses are an address block
assigned to a site by each service provider to which a site
connects. Typically, each block is a sub-block of a service
provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
is aggregated into the larger block before being advertised into
the underlay network. Traditionally, IP multihoming has been
implemented by each multihomed site acquiring its own globally
visible prefix.
Provider-Independent (PI) Addresses: PI addresses are an address
block assigned from a pool where blocks are not associated with
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.
Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A 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 PITR acts like an ITR but does so on behalf of non-LISP sites that
send packets to destinations at LISP sites. send packets to destinations at LISP sites.
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. header.
Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to 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 remove a LISP header, then acts as an ITR to prepend a new LISP
header. This is known as Re-encapsulating Tunneling. Doing this header. This is known as Re-encapsulating Tunneling. Doing this
allows a packet to be re-routed by the RTR without adding the allows a packet to be re-routed by the RTR without adding the
overhead of additional tunnel headers. Any references to tunnels overhead of additional tunnel headers. When using multiple
in this specification refer to dynamic encapsulating tunnels; they mapping database systems, care must be taken to not create re-
are never statically configured. When using multiple mapping
database systems, care must be taken to not create re-
encapsulation loops through misconfiguration. encapsulation loops through misconfiguration.
Route-Returnability: Route-returnability is an assumption that the 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.
Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6
[RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is
the output of an EID-to-RLOC mapping lookup. An EID maps to one the output of an EID-to-RLOC mapping lookup. An EID maps to zero
or more RLOCs. Typically, RLOCs are numbered from aggregatable or more RLOCs. Typically, RLOCs are numbered from blocks that are
blocks that are assigned to a site at each point to which it assigned to a site at each point to which it attaches to the
attaches to the underlay network; where the topology is defined by underlay network; where the topology is defined by the
the connectivity of provider networks. Multiple RLOCs can be connectivity of provider networks. Multiple RLOCs can be assigned
assigned to the same ETR device or to multiple ETR devices at a to the same ETR device or to multiple ETR devices at a site.
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. destination EID.
TE-ETR: A TE-ETR is an ETR that is deployed in a service provider 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 network that strips an outer LISP header for Traffic Engineering
purposes. purposes.
TE-ITR: A TE-ITR is an ITR that is deployed in a service provider TE-ITR: A TE-ITR is an ITR that is deployed in a service provider
skipping to change at page 9, line 44 skipping to change at page 9, line 28
prepends LISP headers on host-originated packets and strips them prepends LISP headers on host-originated packets and strips them
prior to final delivery to their destination. The IP addresses in prior to final delivery to their destination. The IP addresses in
this "outer header" are RLOCs. During end-to-end packet exchange this "outer header" are RLOCs. During end-to-end packet exchange
between two Internet hosts, an ITR prepends a new LISP header to each between two Internet hosts, an ITR prepends a new LISP header to each
packet, and an ETR strips the new header. The ITR performs EID-to- packet, and an ETR strips the new header. The ITR performs EID-to-
RLOC lookups to determine the routing path to the ETR, which has the RLOC lookups to determine the routing path to the ETR, which has the
RLOC as one of its IP addresses. RLOC as one of its IP addresses.
Some basic rules governing LISP are: Some basic rules governing LISP are:
o End-systems only send to addresses that are EIDs. They don't know o End-systems only send to addresses that are EIDs. EIDs are
that addresses are EIDs versus RLOCs but assume that packets get typically IP addresses assigned to hosts (other types of EID are
to their intended destinations. In a system where LISP is supported by LISP, see [RFC8060] for further information). End-
deployed, LISP routers intercept EID-addressed packets and assist systems don't know that addresses are EIDs versus RLOCs but assume
in delivering them across the network core where EIDs cannot be that packets get to their intended destinations. In a system
routed. The procedure a host uses to send IP packets does not where LISP is deployed, LISP routers intercept EID-addressed
change. packets and assist in delivering them across the network core
where EIDs cannot be routed. The procedure a host uses to send IP
o EIDs are typically IP addresses assigned to hosts. packets does not change.
o Other types of EID are supported by LISP, see [RFC8060] for
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
skipping to change at page 10, line 32 skipping to change at page 10, line 13
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
that is optimized for administrative convenience and to facilitate
scaling of the EID-to-RLOC mapping database.
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
skipping to change at page 13, line 5 skipping to change at page 12, line 32
8. The ETR receives these packets directly (since the destination 8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), checks the validity address is one of its assigned IP addresses), checks the validity
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 "glean mapping" and only contains
contains a single RLOC for the EID in question. More complete a single RLOC for the EID in question. More complete information
information about additional RLOCs SHOULD be verified by sending about additional RLOCs SHOULD be verified by sending a LISP Map-
a LISP Map-Request for that EID. Both the ITR and the ETR MAY Request for that EID. Both the ITR and the ETR MAY also
also influence the decision the other makes in selecting an RLOC. 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.
skipping to change at page 17, line 48 skipping to change at page 17, line 15
x x x x 1 x x x x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Nonce/Map-Version | |N|L|E|V|I|R|K|K| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs | | Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: The R-bit is a Reserved bit for future use. It MUST be set to 0 R: The R-bit is a Reserved bit for future use. It MUST be set to 0
on transmit and MUST be ignored on receipt. on transmit and MUST be ignored on receipt.
KK: The KK-bits are a 2-bit field used when encapsualted packets are KK: The KK-bits are a 2-bit field used when encapsulated packets are
encrypted. The field is set to 00 when the packet is not encrypted. The field is set to 00 when the packet is not
encrypted. See [RFC8061] for further information. encrypted. See [RFC8061] for further information.
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is
randomly generated by an ITR when the N-bit is set to 1. Nonce randomly generated by an ITR when the N-bit is set to 1. Nonce
generation algorithms are an implementation matter but are generation algorithms are an implementation matter but are
required to generate different nonces when sending to different required to generate different nonces when sending to different
destinations. However, the same nonce can be used for a period of destinations. However, the same nonce can be used for a period of
time to the same destination. The nonce is also used when the time when encapsulating to the same ETR. The nonce is also used
E-bit is set to request the nonce value to be echoed by the other when the E-bit is set to request the nonce value to be echoed by
side when packets are returned. When the E-bit is clear but the the other side when packets are returned. When the E-bit is clear
N-bit is set, a remote ITR is either echoing a previously but the N-bit is set, a remote ITR is either echoing a previously
requested echo-nonce or providing a random nonce. See requested echo-nonce or providing a random nonce. See
Section 10.1 for more details. Section 10.1 for more details.
LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the
'Locator-Status-Bits' field in the LISP header is set by an ITR to 'Locator-Status-Bits' field in the LISP header is set by an ITR to
indicate to an ETR the up/down status of the Locators in the indicate to an ETR the up/down status of the Locators in the
source site. Each RLOC in a Map-Reply is assigned an ordinal source site. Each RLOC in a Map-Reply is assigned an ordinal
value from 0 to n-1 (when there are n RLOCs in a mapping entry). value from 0 to n-1 (when there are n RLOCs in a mapping entry).
The Locator-Status-Bits are numbered from 0 to n-1 from the least The Locator-Status-Bits are numbered from 0 to n-1 from the least
significant bit of the field. The field is 32 bits when the I-bit significant bit of the field. The field is 32 bits when the I-bit
skipping to change at page 18, line 42 skipping to change at page 18, line 9
that the inner-header source EID address matches. If the LSB for that the inner-header source EID address matches. If the LSB for
an anycast Locator is set to 1, then there is at least one RLOC an anycast Locator is set to 1, then there is at least one RLOC
with that address, and the ETR is considered 'up'. with that address, and the ETR is considered 'up'.
When doing ITR/PITR encapsulation: When doing ITR/PITR encapsulation:
o The outer-header 'Time to Live' field (or 'Hop Limit' field, in o The outer-header 'Time to Live' field (or 'Hop Limit' field, in
the case of IPv6) SHOULD be copied from the inner-header 'Time to the case of IPv6) SHOULD be copied from the inner-header 'Time to
Live' field. Live' field.
o The outer-header 'Type of Service' field (or the 'Traffic Class' o The outer-header 'Differentiated Services Code Point' (DSCP) field
field, in the case of IPv6) SHOULD be copied from the inner-header (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
'Type of Service' field (with one exception; see below). copied from the inner-header DSCP field ('Traffic Class' field, in
the case of IPv6) considering the exception listed below.
o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC3168].
ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
header to the outer header. Re-encapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the new outer
header.
When doing ETR/PETR decapsulation: When doing ETR/PETR decapsulation:
o The inner-header 'Time to Live' field (or 'Hop Limit' field, in o The inner-header 'Time to Live' field (or 'Hop Limit' field, in
the case of IPv6) SHOULD be copied from the outer-header 'Time to the case of IPv6) SHOULD be copied from the outer-header 'Time to
Live' field, when the Time to Live value of the outer header is Live' field, when the Time to Live value of the outer header is
less than the Time to Live value of the inner header. Failing to less than the Time to Live value of the inner header. Failing to
perform this check can cause the Time to Live of the inner header perform this check can cause the Time to Live of the inner header
to increment across encapsulation/decapsulation cycles. This to increment across encapsulation/decapsulation cycles. This
check is also performed when doing initial encapsulation, when a check is also performed when doing initial encapsulation, when a
packet comes to an ITR or PITR destined for a LISP site. packet comes to an ITR or PITR destined for a LISP site.
o The inner-header 'Type of Service' field (or the 'Traffic Class' o The inner-header 'Differentiated Services Code Point' (DSCP) field
field, in the case of IPv6) SHOULD be copied from the outer-header (or the 'Traffic Class' field, in the case of IPv6) SHOULD be
'Type of Service' field (with one exception; see below). copied from the outer-header DSCP field ('Traffic Class' field, in
the case of IPv6) considering the exception listed below.
o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
of the IPv6 'Traffic Class' field) requires special treatment in
order to avoid discarding indications of congestion [RFC3168]. If
the 'ECN' field contains a congestion indication codepoint (the
value is '11', the Congestion Experienced (CE) codepoint), then
ETR decapsulation MUST copy the 2-bit 'ECN' field from the
stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR. These requirements preserve
CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between
the tunnel endpoints.
Note that if an ETR/PETR is also an ITR/PITR and chooses to re- Note that if an ETR/PETR is also an ITR/PITR and chooses to re-
encapsulate after decapsulating, the net effect of this is that the encapsulate after decapsulating, the net effect of this is that the
new outer header will carry the same Time to Live as the old outer new outer header will carry the same Time to Live as the old outer
header minus 1. header minus 1.
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
skipping to change at page 20, line 5 skipping to change at page 19, line 41
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
EID is done to the map-cache. EID is done to the map-cache.
When the lookup succeeds, the locator-set retrieved from the map- When the lookup succeeds, the Locator-Set retrieved from the map-
cache is used to send the packet to the EID's topological location. cache is used to send the packet to the EID's topological location.
If the lookup fails, the ITR/PITR needs to retrieve the mapping using If the lookup fails, the ITR/PITR needs to retrieve the mapping using
the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The
mapping is then stored in the local map-cache to forward subsequent mapping is then stored in the local map-cache to forward subsequent
packets addressed to the same EID-prefix. packets addressed to the same EID-prefix.
The map-cache is a local cache of mappings, entries are expired based The map-cache is a local cache of mappings, entries are expired based
on the associated Time to live. In addition, entries can be updated on the associated Time to live. In addition, entries can be updated
with more current information, see Section 13 for further information with more current information, see Section 13 for further information
skipping to change at page 23, line 32 skipping to change at page 23, line 17
list according to the weighting assigned by the server-side. In list according to the weighting assigned by the server-side. In
this case, the server-side controls both the subset list and load- this case, the server-side controls both the subset list and load-
splitting across its members. The client-side can use RLOCs splitting across its members. The client-side can use RLOCs
outside of the subset list if it determines that the subset list outside of the subset list if it determines that the subset list
is unreachable (unless RLOCs are set to a Priority of 255). Some is unreachable (unless RLOCs are set to a Priority of 255). Some
sharing of control exists: the server-side determines the sharing of control exists: the server-side determines the
destination RLOC list and load distribution while the client-side destination RLOC list and load distribution while the client-side
has the option of using alternatives to this list if RLOCs in the has the option of using alternatives to this list if RLOCs in the
list are unreachable. list are unreachable.
o The server-side sets a Weight of 0 for the RLOC subset list. In o The server-side sets a Weight of zero for the RLOC subset list.
this case, the client-side can choose how the traffic load is In this case, the client-side can choose how the traffic load is
spread across the subset list. Control is shared by the server- spread across the subset list. Control is shared by the server-
side determining the list and the client determining load side determining the list and the client-side determining load
distribution. Again, the client can use alternative RLOCs if the distribution. Again, the client can use alternative RLOCs if the
server-provided list of RLOCs is unreachable. server-provided list of RLOCs is unreachable.
o Either side (more likely the server-side ETR) decides not to send o Either side (more likely the server-side ETR) decides not to send
a Map-Request. For example, if the server-side ETR does not send a Map-Request. For example, if the server-side ETR does not send
Map-Requests, it gleans RLOCs from the client-side ITR, giving the Map-Requests, it gleans RLOCs from the client-side ITR, giving the
client-side ITR responsibility for bidirectional RLOC reachability client-side ITR responsibility for bidirectional RLOC reachability
and preferability. Server-side ETR gleaning of the client-side and preferability. Server-side ETR gleaning of the client-side
ITR RLOC is done by caching the inner-header source EID and the ITR RLOC is done by caching the inner-header source EID and the
outer-header source RLOC of received packets. The client-side ITR outer-header source RLOC of received packets. The client-side ITR
skipping to change at page 24, line 45 skipping to change at page 24, line 30
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 [I-D.ietf-opsec-icmp-filtering].
3. An ITR that participates in the global routing system can 3. When an ITR participates in the routing protocol that operates in
determine that an RLOC is down if no BGP Routing Information Base the underlay routing system, it can determine that an RLOC is
(RIB) route exists that matches the RLOC IP address. down when no Routing Information Base (RIB) entry 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.
skipping to change at page 37, line 34 skipping to change at page 37, line 15
in LISP Map-Servers and Map-Resolvers) and are provided on demand to in LISP Map-Servers and Map-Resolvers) and are provided on demand to
only the correspondents of the LISP mobile node. only the correspondents of the LISP mobile node.
Refer to [I-D.ietf-lisp-mn] for more details for when the EID and Refer to [I-D.ietf-lisp-mn] for more details for when the EID and
RLOC are co-located in the roaming node. RLOC are co-located in the roaming node.
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 network 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
skipping to change at page 39, line 50 skipping to change at page 39, line 33
capture some of the reasoning behind this preference for implementing capture some of the reasoning behind this preference for implementing
LISP on CE routers. LISP on CE routers.
The use of ISP PE routers for xTR placement gives an ISP, rather than The use of ISP PE routers for xTR placement gives an ISP, rather than
a site, control over the location of the ETRs. That is, the ISP can a site, control over the location of the ETRs. That is, the ISP can
decide whether the xTRs are in the destination site (in either CE decide whether the xTRs are in the destination site (in either CE
xTRs or last-hop xTRs within a site) or at other PE edges. The xTRs or last-hop xTRs within a site) or at other PE edges. The
advantage of this case is that two encapsulation headers can be advantage of this case is that two encapsulation headers can be
avoided. By having the PE be the first router on the path to avoided. By having the PE be the first router on the path to
encapsulate, it can choose a TE path first, and the ETR can encapsulate, it can choose a TE path first, and the ETR can
decapsulate and Re-Encapsulate for a new encapsuluation path to the decapsulate and Re-Encapsulate for a new encapsulation path to the
destination end site. destination end site.
An obvious disadvantage is that the end site has no control over An obvious disadvantage is that the end site has no control over
where its packets flow or over the RLOCs used. Other disadvantages where its packets flow or over the RLOCs used. Other disadvantages
include difficulty in synchronizing path liveness updates between CE include difficulty in synchronizing path liveness updates between CE
and PE routers. and PE routers.
As mentioned in earlier sections, a combination of these scenarios is As mentioned in earlier sections, a combination of these scenarios is
possible at the expense of extra packet header overhead; if both site possible at the expense of extra packet header overhead; if both site
and provider want control, then Recursive or Re-Encapsulating Tunnels and provider want control, then Recursive or Re-Encapsulating Tunnels
skipping to change at page 43, line 7 skipping to change at page 42, line 36
expecting addresses from intermediate hops in the same address format expecting addresses from intermediate hops in the same address format
for the type of traceroute it originated. Therefore, in this case, for the type of traceroute it originated. Therefore, in this case,
segment 2 will make the tunnel look like one hop. All the ITR has to segment 2 will make the tunnel look like one hop. All the ITR has to
do to make this work is to not copy the inner TTL to the outer, do to make this work is to not copy the inner TTL to the outer,
encapsulating header's TTL when a traceroute packet is encapsulated encapsulating header's TTL when a traceroute packet is encapsulated
using an RLOC from a different address family. This will cause no using an RLOC from a different address family. This will cause no
TTL decrement to 0 to occur in core routers between the ITR and ETR. TTL decrement to 0 to occur in core routers between the ITR and ETR.
19. Security Considerations 19. Security Considerations
Security considerations for LISP are discussed in [RFC7833], in Security considerations for LISP are discussed in [RFC7833].
addition [I-D.ietf-lisp-sec] provides authentication and integrity to
LISP mappings.
A complete LISP threat analysis can be found in [RFC7835], in what A complete LISP threat analysis can be found in [RFC7835], in what
follows we provide a summary. follows we provide a summary.
The optional mechanisms of gleaning is offered to directly obtain a The optional mechanisms of gleaning is offered to directly obtain a
mapping from the LISP encapsulated packets. Specifically, an xTR can mapping from the LISP encapsulated packets. Specifically, an xTR can
learn the EID-to-RLOC mapping by inspecting the source RLOC and learn the EID-to-RLOC mapping by inspecting the source RLOC and
source EID of an encapsulated packet, and insert this new mapping source EID of an encapsulated packet, and insert this new mapping
into its map-cache. An off-path attacker can spoof the source EID into its map-cache. An off-path attacker can spoof the source EID
address to divert the traffic sent to the victim's spoofed EID. If address to divert the traffic sent to the victim's spoofed EID. If
the attacker spoofs the source RLOC, it can mount a DoS attack by the attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim;s RLOC, potentially redirecting traffic to the spoofed victim's RLOC, potentially
overloading it. overloading it.
The LISP Data-Plane defines several mechanisms to monitor RLOC data- The LISP Data-Plane defines several mechanisms to monitor RLOC data-
plane reachability, in this context Locator-Status Bits, Nonce- plane reachability, in this context Locator-Status Bits, Nonce-
Present and Echo-Nonce bits of the LISP encapsulation header can be Present and Echo-Nonce bits of the LISP encapsulation header can be
manipulated by an attacker to mount a DoS attack. An off-path manipulated by an attacker to mount a DoS attack. An off-path
attacker able to spoof the RLOC of a victim's xTR can manipulate such attacker able to spoof the RLOC of a victim's xTR can manipulate such
mechanisms to declare a set of RLOCs unreachable. This can be used mechanisms to declare a set of RLOCs unreachable. This can be used
also, for instance, to declare only one RLOC reachable with the aim also, for instance, to declare only one RLOC reachable with the aim
of overload it. of overload it.
skipping to change at page 44, line 13 skipping to change at page 43, line 38
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 [RFC8126]. 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 number 4341 for the LISP
lisp-data and lisp-control operation, respectively. IANA has updated data-plane. IANA has updated the description for UDP port 4341 as
the description for UDP ports 4341 and 4342 as follows: follows:
lisp-data 4341 udp LISP Data Packets lisp-data 4341 udp LISP Data Packets
lisp-control 4342 udp LISP Control Packets
22. References 22. References
22.1. Normative References 22.1. Normative References
[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-07 (work in progress), December draft-ietf-lisp-rfc6833bis-07 (work in progress), December
2017. 2017.
skipping to change at page 46, line 42 skipping to change at page 46, line 25
[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-07 (work in draft-ietf-lisp-signal-free-multicast-07 (work in
progress), November 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-01 (work in Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in
progress), November 2017. progress), November 2017.
[I-D.ietf-opsec-icmp-filtering]
Gont, F., Gont, G., and C. Pignataro, "Recommendations for
filtering ICMP messages", draft-ietf-opsec-icmp-
filtering-04 (work in progress), July 2013.
[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.
[OPENLISP] [OPENLISP]
skipping to change at page 51, line 5 skipping to change at page 50, 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-08 B.1. Changes to draft-ietf-lisp-rfc6830bis-09
o Posted January 2018.
o Add more details in section 5.3 about DSCP processing during
encapsulation and decapsulation.
o Added clarity to definitions in the Definition of Terms section
from various commenters.
o Removed PA and PI definitions from Definition of Terms section.
o More editorial changes.
o Removed 4342 from IANA section and move to RFC6833 IANA section.
B.2. Changes to draft-ietf-lisp-rfc6830bis-08
o Posted January 2018. o Posted January 2018.
o Remove references to research work for any protocol mechanisms. o Remove references to research work for any protocol mechanisms.
o Document scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 compliant.
o Made changes to reflect comments from document WG shepherd Luigi o Made changes to reflect comments from document WG shepherd Luigi
Iannone. Iannone.
o Ran IDNITs on the document. o Ran IDNITs on the document.
B.2. Changes to draft-ietf-lisp-rfc6830bis-07 B.3. 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.3. Changes to draft-ietf-lisp-rfc6830bis-06 B.4. 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 51, line 48 skipping to change at page 51, line 15
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.4. Changes to draft-ietf-lisp-rfc6830bis-05 B.5. 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.5. Changes to draft-ietf-lisp-rfc6830bis-04 B.6. 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.6. Changes to draft-ietf-lisp-rfc6830bis-03 B.7. 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.7. Changes to draft-ietf-lisp-rfc6830bis-02 B.8. 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.8. Changes to draft-ietf-lisp-rfc6830bis-01 B.9. 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.9. Changes to draft-ietf-lisp-rfc6830bis-00 B.10. 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. 52 change blocks. 
125 lines changed or deleted 142 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/