draft-ietf-lisp-rfc6830bis-11.txt   draft-ietf-lisp-rfc6830bis-12.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: September 6, 2018 D. Lewis Expires: September 20, 2018 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
March 5, 2018 March 19, 2018
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-11 draft-ietf-lisp-rfc6830bis-12
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.
LISP requires no change to either host protocol stacks or to underlay LISP requires no change to either host protocol stacks or to underlay
routers and offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming and mobility,
among other features. among other features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on September 20, 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 42 skipping to change at page 2, line 42
7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19
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 . . . . . . . 21 8. Using Virtualization and Segmentation with LISP . . . . . . . 21
9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 26 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 26
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 29 13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 29
13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 29
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 15. Router Performance Considerations . . . . . . . . . . . . . . 30
15. Router Performance Considerations . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31
17. Network Management Considerations . . . . . . . . . . . . . . 32 17. Network Management Considerations . . . . . . . . . . . . . . 32
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 33 18.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 32
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
19.1. Normative References . . . . . . . . . . . . . . . . . . 33 19.1. Normative References . . . . . . . . . . . . . . . . . . 32
19.2. Informative References . . . . . . . . . . . . . . . . . 34 19.2. Informative References . . . . . . . . . . . . . . . . . 33
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 38
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 38
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 B.1. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 39
B.1. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 40 B.2. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 39
B.2. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 40 B.3. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 39
B.3. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 39
B.4. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 40
B.5. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 41 B.6. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 40
B.6. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 41 B.7. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 40
B.7. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 41 B.8. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 41
B.8. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 41 B.9. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 41
B.9. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 42 B.10. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 41
B.10. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 42 B.11. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 41
B.11. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 42 B.12. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 41
B.12. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 42 B.13. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
This document describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
(LISP). LISP is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built around the
fundamental idea of separating the topological location of a network fundamental idea of separating the topological location of a network
attachment point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. As a result
LISP creates two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers (EIDs), that are
used to identify end-hosts (e.g., nodes or Virtual Machines) and used to identify end-hosts (e.g., nodes or Virtual Machines) and
routable Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify network
attachment points. LISP then defines functions for mapping between attachment points. LISP then defines functions for mapping between
the two namespaces and for encapsulating traffic originated by the two namespaces and for encapsulating traffic originated by
devices using non-routable EIDs for transport across a network devices using non-routable EIDs for transport across a network
infrastructure that routes and forwards using RLOCs. LISP infrastructure that routes and forwards using RLOCs. LISP
encapsulation uses a dynamic form of tunneling where no static encapsulation uses a dynamic form of tunneling where no static
provisioning is required or necessary. provisioning is required or necessary.
LISP is an overlay protocol that separates control from data-plane, LISP is an overlay protocol that separates control from Data-Plane,
this document specifies the data-plane, how LISP-capable routers this document specifies the Data-Plane, how LISP-capable routers
(Tunnel Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating them to the
appropriate location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped with a cache,
called map-cache, that contains EID-to-RLOC mappings. The map-cache called Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache
is populated using the LISP Control-Plane protocol is populated using the LISP Control-Plane protocol
[I-D.ietf-lisp-rfc6833bis]. [I-D.ietf-lisp-rfc6833bis].
LISP does not require changes to either host protocol stack or to LISP does not require changes to either host protocol stack or to
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definition of Terms 3. Definition of Terms
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 that pertains to address encoding in a packet. An address family that pertains to
the data-plane. See [AFN] and [RFC3232] for details. An AFI the Data-Plane. See [AFN] and [RFC3232] for details. An AFI
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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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. Note that there MAY be transient globally visible IP addresses. Note that there MAY be transient
conditions when the EID-Prefix for the site and Locator-Set for 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 each EID-Prefix may not be the same on all ETRs. This has no
negative implications, since a partial set of Locators can be negative implications, since a partial set of Locators can be
used. used.
EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is generally EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is generally
short-lived, on-demand table in an ITR that stores, tracks, and is short-lived, on-demand table in an ITR that stores, tracks, and is
responsible for timing out and otherwise validating EID-to-RLOC responsible for timing out and otherwise validating EID-to-RLOC
mappings. This cache is distinct from the full "database" of EID- mappings. This cache is distinct from the full "database" of EID-
to-RLOC mappings; it is dynamic, local to the ITR(s), and to-RLOC mappings; it is dynamic, local to the ITR(s), and
relatively small, while the database is distributed, relatively relatively small, while the database is distributed, relatively
static, and much more global in scope. static, and much more global in scope.
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. EID-Prefix Prefixes are associated with a set of RLOC addresses. EID-Prefix
skipping to change at page 10, line 32 skipping to change at page 10, line 32
host. Similarly, the ETR might be the last-hop router directly host. Similarly, the ETR might be the last-hop router directly
connected to the destination host. Another example, perhaps for a connected to the destination host. Another example, perhaps for a
VPN service outsourced to an ISP by a site, the ITR could be the VPN service outsourced to an ISP by a site, the ITR could be the
site's border router at the service provider attachment point. site's border router at the service provider attachment point.
Mixing and matching of site-operated, ISP-operated, and other Tunnel Mixing and matching of site-operated, ISP-operated, and other Tunnel
Routers is allowed for maximum flexibility. Routers is allowed for maximum flexibility.
4.1. Packet Flow Sequence 4.1. Packet Flow Sequence
This section provides an example of the unicast packet flow, This section provides an example of the unicast packet flow,
including also control-plane information as specified in including also Control-Plane information as specified in
[I-D.ietf-lisp-rfc6833bis]. The example also assumes the following [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following
conditions: conditions:
o Source host "host1.abc.example.com" is sending a packet to o Source host "host1.abc.example.com" is sending a packet to
"host2.xyz.example.com", exactly what host1 would do if the site "host2.xyz.example.com", exactly what host1 would do if the site
was not using LISP. was not using LISP.
o Each site is multihomed, so each Tunnel Router has an address o Each site is multihomed, so each Tunnel Router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular Tunnel Router is attached. provider to which that particular Tunnel Router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively, but the source and destination can be destination, respectively, but the source and destination can be
located anywhere in the LISP site. located anywhere in the LISP site.
o A Map-Request is sent for an external destination when the o A Map-Request is sent for an external destination when the
destination is not found in the forwarding table or matches a destination is not found in the forwarding table or matches a
default route. Map-Requests are sent to the mapping database default route. Map-Requests are sent to the mapping database
system by using the LISP control-plane protocol documented in system by using the LISP Control-Plane protocol documented in
[I-D.ietf-lisp-rfc6833bis]. [I-D.ietf-lisp-rfc6833bis].
o Map-Replies are sent on the underlying routing system topology o Map-Replies are sent on the underlying routing system topology
using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol. using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol.
Client host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate with server
host2.xyz.example.com: host2.xyz.example.com:
1. host1.abc.example.com wants to open a TCP connection to 1. host1.abc.example.com wants to open a TCP connection to
host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally assigned address of address is the destination EID. The locally assigned address of
host1.abc.example.com is used as the source EID. An IPv4 or IPv6 host1.abc.example.com is used as the source EID. An IPv4 or IPv6
packet is built and forwarded through the LISP site as a normal packet is built and forwarded through the LISP site as a normal
skipping to change at page 11, line 44 skipping to change at page 11, line 44
5. The ETR looks at the destination EID of the Map-Request and 5. The ETR looks at the destination EID of the Map-Request and
matches it against the prefixes in the ETR's configured EID-to- matches it against the prefixes in the ETR's configured EID-to-
RLOC mapping database. This is the list of EID-Prefixes the ETR RLOC mapping database. This is the list of EID-Prefixes the ETR
is supporting for the site it resides in. If there is no match, is supporting for the site it resides in. If there is no match,
the Map-Request is dropped. Otherwise, a LISP Map-Reply is the Map-Request is dropped. Otherwise, a LISP Map-Reply is
returned to the ITR. returned to the ITR.
6. The ITR receives the Map-Reply message, parses the message (to 6. The ITR receives the Map-Reply message, parses the message (to
check for format validity), and stores the mapping information check for format validity), and stores the mapping information
from the packet. This information is stored in the ITR's EID-to- from the packet. This information is stored in the ITR's EID-to-
RLOC map-cache. Note that the map-cache is an on-demand cache. RLOC Map-Cache. Note that the Map-Cache is an on-demand cache.
An ITR will manage its map-cache in such a way that optimizes for An ITR will manage its Map-Cache in such a way that optimizes for
its resource constraints. its resource constraints.
7. Subsequent packets from host1.abc.example.com to 7. Subsequent packets from host1.abc.example.com to
host2.xyz.example.com will have a LISP header prepended by the host2.xyz.example.com will have a LISP header prepended by the
ITR using the appropriate RLOC as the LISP header destination ITR using the appropriate RLOC as the LISP header destination
address learned from the ETR. Note that the packet MAY be sent address learned from the ETR. Note that the packet MAY be sent
to a different ETR than the one that returned the Map-Reply due to a different ETR than the one that returned the Map-Reply due
to the source site's hashing policy or the destination site's to the source site's hashing policy or the destination site's
Locator-Set policy. Locator-Set policy.
skipping to change at page 16, line 20 skipping to change at page 16, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored
and has no meaning when the N-bit is set to 0. When the N-bit is and has no meaning when the N-bit is set to 0. When the N-bit is
set to 1 and this bit is set to 1, an ITR is requesting that the set to 1 and this bit is set to 1, an ITR is requesting that the
nonce value in the 'Nonce' field be echoed back in LISP- nonce value in the 'Nonce' field be echoed back in LISP-
encapsulated packets when the ITR is also an ETR. See encapsulated packets when the ITR is also an ETR. See
Section 10.1 for details. Section 10.1 for details.
V: The V-bit is the Map-Version present bit. When this bit is set to V: The V-bit is the Map-Version present bit. When this bit is set to
1, the N-bit MUST be 0. Refer to Section 13.2 for more details. 1, the N-bit MUST be 0. Refer to Section 13.1 for more details.
This bit indicates that the LISP header is encoded in this This bit indicates that the LISP header is encoded in this
case as: case as:
0 x 0 1 x x x x 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits | | Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 9 skipping to change at page 17, line 9
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 encapsulated 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 RLOCs. However, the same nonce can be used for a period of time
time when encapsulating to the same ETR. The nonce is also used when encapsulating to the same ETR. The nonce is also used when
when the E-bit is set to request the nonce value to be echoed by the E-bit is set to request the nonce value to be echoed by the
the other side when packets are returned. When the E-bit is clear other side when packets are returned. When the E-bit is clear but
but the N-bit is set, a remote ITR is either echoing a previously 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 19, line 23 skipping to change at page 19, line 23
6. LISP EID-to-RLOC Map-Cache 6. LISP EID-to-RLOC Map-Cache
ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to-
RLOC Map-Cache, that contains mappings from EID-prefixes to locator RLOC Map-Cache, that contains mappings from EID-prefixes to locator
sets. The cache is used to encapsulate packets from the EID space to sets. The cache is used to encapsulate packets from the EID space to
the corresponding RLOC network attachment point. the corresponding RLOC network attachment point.
When an ITR/PITR receives a packet from inside of the LISP site to When an ITR/PITR receives a packet from inside of the LISP site to
destinations outside of the site a longest-prefix match lookup of the destinations outside of the site a longest-prefix match lookup of the
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
on this. Finally, the map-cache also contains reachability on this. Finally, the Map-Cache also contains reachability
information about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP reachability
information mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability of RLOCs, see
Section 10 for the specific mechanisms. Section 10 for the specific mechanisms.
7. Dealing with Large Encapsulated Packets 7. Dealing with Large Encapsulated Packets
This section proposes two mechanisms to deal with packets that exceed This section proposes two mechanisms to deal with packets that exceed
the path MTU between the ITR and ETR. the path MTU between the ITR and ETR.
It is left to the implementor to decide if the stateless or stateful It is left to the implementor to decide if the stateless or stateful
skipping to change at page 22, line 16 skipping to change at page 22, line 16
When an ETR decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup. to use for the inner destination EID lookup.
For example, an 802.1Q VLAN tag or VPN identifier could be used as a For example, an 802.1Q VLAN tag or VPN identifier could be used as a
24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case
details. details.
The Instance ID that is stored in the mapping database when LISP-DDT The Instance ID that is stored in the mapping database when LISP-DDT
[RFC8111] is used is 32 bits in length. That means the control-plane [RFC8111] is used is 32 bits in length. That means the Control-Plane
can store more instances than a given data-plane can use. Multiple can store more instances than a given Data-Plane can use. Multiple
data-planes can use the same 32-bit space as long as the low-order 24 Data-Planes can use the same 32-bit space as long as the low-order 24
bits don't overlap among xTRs. bits don't overlap among xTRs.
9. Routing Locator Selection 9. Routing Locator Selection
The map-cache contains the state used by ITRs and PITRs to The Map-Cache contains the state used by ITRs and PITRs to
encapsulate packets. When an ITR/PITR receives a packet from inside encapsulate packets. When an ITR/PITR receives a packet from inside
the LISP site to a destination outside of the site a longest-prefix the LISP site to a destination outside of the site a longest-prefix
match lookup of the EID is done to the map-cache (see Section 6). match lookup of the EID is done to the Map-Cache (see Section 6).
The lookup returns a single Locator-Set containing a list of RLOCs The lookup returns a single Locator-Set containing a list of RLOCs
corresponding to the EID's topological location. Each RLOC in the corresponding to the EID's topological location. Each RLOC in the
Locator-Set is associated with a 'Priority' and 'Weight', this Locator-Set is associated with a 'Priority' and 'Weight', this
information is used to select the RLOC to encapsulate. information is used to select the RLOC to encapsulate.
The RLOC with the lowest 'Priority' is selected. An RLOC with The RLOC with the lowest 'Priority' is selected. An RLOC with
'Priority' 255 means that MUST NOT be used for forwarding. When 'Priority' 255 means that MUST NOT be used for forwarding. When
multiple RLOC have the same 'Priority' then the 'Weight' states how multiple RLOC have the same 'Priority' then the 'Weight' states how
to load balance traffic among them. The value of the 'Weight' to load balance traffic among them. The value of the 'Weight'
represents the relative weight of the total packets that match the represents the relative weight of the total packets that match the
skipping to change at page 24, line 10 skipping to change at page 24, line 10
reachable when the R-bit for the Locator record is set to 1. When reachable when the R-bit for the Locator record is set to 1. When
the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the
RLOC. Neither the information contained in a Map-Reply nor that RLOC. Neither the information contained in a Map-Reply nor that
stored in the mapping database system provides reachability stored in the mapping database system provides reachability
information for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not part of the
mapping system and is determined using one or more of the Routing mapping system and is determined using one or more of the Routing
Locator reachability algorithms described in the next section. Locator reachability algorithms described in the next section.
10. Routing Locator Reachability 10. Routing Locator Reachability
Several data-plane mechanisms for determining RLOC reachability are Several Data-Plane mechanisms for determining RLOC reachability are
currently defined. Please note that additional control-plane based currently defined. Please note that additional Control-Plane based
reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis].
1. An ETR MAY examine the Locator-Status-Bits in the LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of
an encapsulated data packet received from an ITR. If the ETR is an encapsulated data packet received from an ITR. If the ETR is
also acting as an ITR and has traffic to return to the original also acting as an ITR and has traffic to return to the original
ITR site, it can use this status information to help select an ITR site, it can use this status information to help select an
RLOC. RLOC.
2. When an ETR receives an encapsulated packet from an ITR, the 2. When an ETR receives an encapsulated packet from an ITR, the
source RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet is likely up.
skipping to change at page 25, line 32 skipping to change at page 25, line 32
most cases, the ETR can also reach the ITR but cannot assume this to most cases, the ETR can also reach the ITR but cannot assume this to
be true, due to the possibility of path asymmetry. In the presence be true, due to the possibility of path asymmetry. In the presence
of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD
NOT use the lack of return traffic as an indication that the ETR is NOT use the lack of return traffic as an indication that the ETR is
unreachable. Instead, it MUST use an alternate mechanism to unreachable. Instead, it MUST use an alternate mechanism to
determine reachability. determine reachability.
10.1. Echo Nonce Algorithm 10.1. Echo Nonce Algorithm
When data flows bidirectionally between Locators from different When data flows bidirectionally between Locators from different
sites, a data-plane mechanism called "nonce echoing" can be used to sites, a Data-Plane mechanism called "nonce echoing" can be used to
determine reachability between an ITR and ETR. When an ITR wants to determine reachability between an ITR and ETR. When an ITR wants to
solicit a nonce echo, it sets the N- and E-bits and places a 24-bit solicit a nonce echo, it sets the N- and E-bits and places a 24-bit
nonce [RFC4086] in the LISP header of the next encapsulated data nonce [RFC4086] in the LISP header of the next encapsulated data
packet. packet.
When this packet is received by the ETR, the encapsulated packet is When this packet is received by the ETR, the encapsulated packet is
forwarded as normal. When the ETR next sends a data packet to the forwarded as normal. When the ETR next sends a data packet to the
ITR, it includes the nonce received earlier with the N-bit set and ITR, it includes the nonce received earlier with the N-bit set and
E-bit cleared. The ITR sees this "echoed nonce" and knows that the E-bit cleared. The ITR sees this "echoed nonce" and knows that the
path to and from the ETR is up. path to and from the ETR is up.
skipping to change at page 27, line 8 skipping to change at page 27, line 8
It is recognized that there are no simple solutions to the site It is recognized that there are no simple solutions to the site
partitioning problem because it is hard to know which part of the partitioning problem because it is hard to know which part of the
EID-Prefix range is partitioned and which Locators can reach any sub- EID-Prefix range is partitioned and which Locators can reach any sub-
ranges of the EID-Prefixes. Note that this is not a new problem ranges of the EID-Prefixes. Note that this is not a new problem
introduced by the LISP architecture. The problem exists today when a introduced by the LISP architecture. The problem exists today when a
multihomed site uses BGP to advertise its reachability upstream. multihomed site uses BGP to advertise its reachability upstream.
12. Routing Locator Hashing 12. Routing Locator Hashing
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message When an ETR provides an EID-to-RLOC mapping in a Map-Reply message
that is stored in the map-cache of a requesting ITR, the Locator-Set that is stored in the Map-Cache of a requesting ITR, the Locator-Set
for the EID-Prefix MAY contain different Priority and Weight values for the EID-Prefix MAY contain different Priority and Weight values
for each locator address. When more than one best Priority Locator for each locator address. When more than one best Priority Locator
exists, the ITR can decide how to load-share traffic against the exists, the ITR can decide how to load-share traffic against the
corresponding Locators. corresponding Locators.
The following hash algorithm MAY be used by an ITR to select a The following hash algorithm MAY be used by an ITR to select a
Locator for a packet destined to an EID for the EID-to-RLOC mapping: Locator for a packet destined to an EID for the EID-to-RLOC mapping:
1. Either a source and destination address hash or the traditional 1. Either a source and destination address hash or the traditional
5-tuple hash can be used. The traditional 5-tuple hash includes 5-tuple hash can be used. The traditional 5-tuple hash includes
skipping to change at page 28, line 16 skipping to change at page 28, line 16
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, it is which ITRs requested its mappings. For scalability reasons, it is
desirable to maintain this approach but need to provide a way for desirable to maintain this approach but need to provide a way for
ETRs to 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.
This section defines data-plane mechanisms for updating EID-to-RLOC This section defines a Data-Plane mechanism for updating EID-to-RLOC
mappings. Additionally, the Solicit-Map Request (SMR) control-plane mappings. Additionally, the Solicit-Map Request (SMR) Control-Plane
updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis]. updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis].
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 29, line 5 skipping to change at page 29, line 5
well as setting the corresponding Locator-Status-Bit to 0. This well as setting the corresponding Locator-Status-Bit to 0. This
forces ITRs with old or new mappings to avoid using the removed forces ITRs with old or new mappings to avoid using the removed
Locator. Locator.
If many changes occur to a mapping over a long period of time, one If many changes occur to a mapping over a long period of time, one
will find empty record slots in the middle of the Locator-Set and new will find empty record slots in the middle of the Locator-Set and new
records appended to the Locator-Set. At some point, it would be records appended to the Locator-Set. At some point, it would be
useful to compact the Locator-Set so the Locator-Status-Bit settings useful to compact the Locator-Set so the Locator-Status-Bit settings
can be efficiently packed. can be efficiently packed.
We propose here two approaches for Locator-Set compaction: one We propose here a Data-Plane mechanism (Map-Versioning) to update the
operational mechanism (clock sweep) and one protocol mechanisms (Map- contents of EID-to-RLOC mappings. Please note that in addition the
Versioning). Please note that in addition the Solicit-Map Request Solicit-Map Request (specified in [I-D.ietf-lisp-rfc6833bis]) is a
(specified in [I-D.ietf-lisp-rfc6833bis]) is a control-plane Control-Plane mechanisms that can be used to update EID-to-RLOC
mechanisms that can be used to update EID-to-RLOC mappings. mappings.
13.1. Clock Sweep
The clock sweep approach uses planning in advance and the use of
count-down TTLs to time out mappings that have already been cached.
The default setting for an EID-to-RLOC mapping TTL is 24 hours. So,
there is a 24-hour window to time out old mappings. The following
clock sweep procedure is used:
1. 24 hours before a mapping change is to take effect, a network
administrator configures the ETRs at a site to start the clock
sweep window.
2. During the clock sweep window, ETRs continue to send Map-Reply
messages with the current (unchanged) mapping records. The TTL
for these mappings is set to 1 hour.
3. 24 hours later, all previous cache entries will have timed out,
and any active cache entries will time out within 1 hour. During
this 1-hour window, the ETRs continue to send Map-Reply messages
with the current (unchanged) mapping records with the TTL set to
1 minute.
4. At the end of the 1-hour window, the ETRs will send Map-Reply
messages with the new (changed) mapping records. So, any active
caches can get the new mapping contents right away if not cached,
or in 1 minute if they had the mapping cached. The new mappings
are cached with a TTL equal to the TTL in the Map-Reply.
13.2. Database Map-Versioning 13.1. Database Map-Versioning
When there is unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an ITR and ETR, and
the EID-to-RLOC mappings change on the ETR, it needs to inform the the EID-to-RLOC mappings change on the ETR, it needs to inform the
ITR so encapsulation to a removed Locator can stop and can instead be ITR so encapsulation to a removed Locator can stop and can instead be
started to a new Locator in the Locator-Set. started to a new Locator in the Locator-Set.
An ETR, when it sends Map-Reply messages, conveys its own Map-Version An ETR, when it sends Map-Reply messages, conveys its own Map-Version
Number. This is known as the Destination Map-Version Number. ITRs Number. This is known as the Destination Map-Version Number. ITRs
include the Destination Map-Version Number in packets they include the Destination Map-Version Number in packets they
encapsulate to the site. When an ETR decapsulates a packet and encapsulate to the site. When an ETR decapsulates a packet and
skipping to change at page 31, line 26 skipping to change at page 30, line 45
few implementation techniques can be used to incrementally implement few implementation techniques can be used to incrementally implement
LISP: LISP:
o When a tunnel-encapsulated packet is received by an ETR, the outer o When a tunnel-encapsulated packet is received by an ETR, the outer
destination address may not be the address of the router. This destination address may not be the address of the router. This
makes it challenging for the control plane to get packets from the makes it challenging for the control plane to get packets from the
hardware. This may be mitigated by creating special Forwarding hardware. This may be mitigated by creating special Forwarding
Information Base (FIB) entries for the EID-Prefixes of EIDs served Information Base (FIB) entries for the EID-Prefixes of EIDs served
by the ETR (those for which the router provides an RLOC by the ETR (those for which the router provides an RLOC
translation). These FIB entries are marked with a flag indicating translation). These FIB entries are marked with a flag indicating
that control-plane processing SHOULD be performed. The forwarding that Control-Plane processing SHOULD be performed. The forwarding
logic of testing for particular IP protocol number values is not logic of testing for particular IP protocol number values is not
necessary. There are a few proven cases where no changes to necessary. There are a few proven cases where no changes to
existing deployed hardware were needed to support the LISP data- existing deployed hardware were needed to support the LISP Data-
plane. Plane.
o On an ITR, prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of adding more
octets to a MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the string as part
of the outgoing encapsulation procedure. Routers that support of the outgoing encapsulation procedure. Routers that support
Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4
tunneling [RFC3056] may already support this action. tunneling [RFC3056] may already support this action.
o A packet's source address or interface the packet was received on o A packet's source address or interface the packet was received on
can be used to select VRF (Virtual Routing/Forwarding). The VRF's can be used to select VRF (Virtual Routing/Forwarding). The VRF's
routing table can be used to find EID-to-RLOC mappings. routing table can be used to find EID-to-RLOC mappings.
For performance issues related to map-cache management, see For performance issues related to Map-Cache management, see
Section 16. Section 16.
16. Security Considerations 16. Security Considerations
Security considerations for LISP are discussed in [RFC7833]. Security considerations for LISP are discussed in [RFC7833].
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.
Map-Versioning is a data-plane mechanism used to signal a peering xTR Map-Versioning is a Data-Plane mechanism used to signal a peering xTR
that a local EID-to-RLOC mapping has been updated, so that the that a local EID-to-RLOC mapping has been updated, so that the
peering xTR uses LISP Control-Plane signaling message to retrieve a peering xTR uses LISP Control-Plane signaling message to retrieve a
fresh mapping. This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to forge the map-
versioning field of a LISP encapsulated header and force an excessive versioning field of a LISP encapsulated header and force an excessive
amount of signaling between xTRs that may overload them. amount of signaling between xTRs that may overload them.
Most of the attack vectors can be mitigated with careful deployment Most of the attack vectors can be mitigated with careful deployment
and configuration, information learned opportunistically (such as LSB and configuration, information learned opportunistically (such as LSB
or gleaning) SHOULD be verified with other reachability mechanisms. or gleaning) SHOULD be verified with other reachability mechanisms.
In addition, systematic rate-limitation and filtering is an effective In addition, systematic rate-limitation and filtering is an effective
technique to mitigate attacks that aim to overload the control-plane. technique to mitigate attacks that aim to overload the Control-Plane.
17. Network Management Considerations 17. Network Management Considerations
Considerations for network management tools exist so the LISP Considerations for network management tools exist so the LISP
protocol suite can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These mechanisms can be
found in [RFC7052] and [RFC6835]. found in [RFC7052] and [RFC6835].
18. IANA Considerations 18. 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].
18.1. LISP UDP Port Numbers 18.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port number 4341 for the LISP The IANA registry has allocated UDP port number 4341 for the LISP
data-plane. IANA has updated the description for UDP port 4341 as Data-Plane. IANA has updated the description for UDP port 4341 as
follows: follows:
lisp-data 4341 udp LISP Data Packets lisp-data 4341 udp LISP Data Packets
19. References 19. References
19.1. Normative References 19.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-09 (work in progress), March
2017. 2018.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
19.2. Informative References 19.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>.
skipping to change at page 34, line 48 skipping to change at page 34, line 7
RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in
progress), November 2017. progress), November 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-14 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017. (work in progress), October 2017.
[I-D.ietf-lisp-signal-free-multicast] [I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-08 (work in draft-ietf-lisp-signal-free-multicast-09 (work in
progress), February 2018. progress), March 2018.
[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.
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin,
"Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix Tenth System
Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), October 1996.
skipping to change at page 36, line 5 skipping to change at page 35, line 11
[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>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005, DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
[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>.
skipping to change at page 36, line 29 skipping to change at page 35, line 40
[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>.
[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>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
skipping to change at page 40, line 5 skipping to change at page 39, 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-11 B.1. Changes to draft-ietf-lisp-rfc6830bis-12
o Posted March IETF Week 2018.
o Clarified that a new nonce is required per RLOC.
o Removed 'Clock Sweep' section. This text must be placed in a new
OAM document.
o Some references changed from normative to informative
B.2. Changes to draft-ietf-lisp-rfc6830bis-11
o Posted March 2018. o Posted March 2018.
o Removed sections 16, 17 and 18 (Mobility, Deployment and o Removed sections 16, 17 and 18 (Mobility, Deployment and
Traceroute considerations). This text must be placed in a new OAM Traceroute considerations). This text must be placed in a new OAM
document. document.
B.2. Changes to draft-ietf-lisp-rfc6830bis-10 B.3. Changes to draft-ietf-lisp-rfc6830bis-10
o Posted March 2018. o Posted March 2018.
o Updated section 'Router Locator Selection' stating that the data- o Updated section 'Router Locator Selection' stating that the Data-
plane MUST follow what's stored in the map-cache (priorities and Plane MUST follow what's stored in the Map-Cache (priorities and
weights). weights).
o Section 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed bullet point 2
(ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port
Unreachable),5 (receive a Map-Reply as a response) and RLOC Unreachable),5 (receive a Map-Reply as a response) and RLOC
probing probing
o Removed 'Solicit-Map Request'. o Removed 'Solicit-Map Request'.
B.3. Changes to draft-ietf-lisp-rfc6830bis-09 B.4. Changes to draft-ietf-lisp-rfc6830bis-09
o Posted January 2018. o Posted January 2018.
o Add more details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP processing during
encapsulation and decapsulation. encapsulation and decapsulation.
o Added clarity to definitions in the Definition of Terms section o Added clarity to definitions in the Definition of Terms section
from various commenters. from various commenters.
o Removed PA and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of Terms section.
o More editorial changes. o More editorial changes.
o Removed 4342 from IANA section and move to RFC6833 IANA section. o Removed 4342 from IANA section and move to RFC6833 IANA section.
B.4. Changes to draft-ietf-lisp-rfc6830bis-08 B.5. 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.5. Changes to draft-ietf-lisp-rfc6830bis-07 B.6. 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.6. Changes to draft-ietf-lisp-rfc6830bis-06 B.7. 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 41, line 40 skipping to change at page 41, line 5
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.7. Changes to draft-ietf-lisp-rfc6830bis-05 B.8. 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.8. Changes to draft-ietf-lisp-rfc6830bis-04 B.9. 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.9. Changes to draft-ietf-lisp-rfc6830bis-03 B.10. 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.10. Changes to draft-ietf-lisp-rfc6830bis-02 B.11. 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.11. Changes to draft-ietf-lisp-rfc6830bis-01 B.12. 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.12. Changes to draft-ietf-lisp-rfc6830bis-00 B.13. 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
 End of changes. 60 change blocks. 
136 lines changed or deleted 118 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/