--- 1/draft-ietf-lisp-rfc6830bis-27.txt 2019-11-17 18:15:41.578798587 -0800 +++ 2/draft-ietf-lisp-rfc6830bis-28.txt 2019-11-17 18:15:41.678801141 -0800 @@ -1,25 +1,25 @@ Network Working Group D. Farinacci Internet-Draft lispers.net Obsoletes: 6830 (if approved) V. Fuller Intended status: Standards Track vaf.net Internet Consulting -Expires: December 18, 2019 D. Meyer +Expires: May 20, 2020 D. Meyer 1-4-5.net D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - June 16, 2019 + November 17, 2019 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-27 + draft-ietf-lisp-rfc6830bis-28 Abstract This document describes the Data-Plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache. @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 18, 2019. + This Internet-Draft will expire on May 20, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,100 +61,102 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 - 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 11 - 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 13 + 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 10 + 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 12 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 - 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 + 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 - 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 - 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 - 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 + 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 + 8. Using Virtualization and Segmentation with LISP . . . . . . . 21 + 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 - 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 + 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 - 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 28 - 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 - 13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 30 - 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 31 - 15. Router Performance Considerations . . . . . . . . . . . . . . 32 + 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 + 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 + 13.1. Locator-Status-Bits . . . . . . . . . . . . . . . . . . 29 + 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29 + 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 + 15. Router Performance Considerations . . . . . . . . . . . . . . 31 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 17. Network Management Considerations . . . . . . . . . . . . . . 33 - 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 34 + 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 20.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 20.2. Informative References . . . . . . . . . . . . . . . . . 36 + 20.2. Informative References . . . . . . . . . . . . . . . . . 35 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 B.1. Changes to draft-ietf-lisp-rfc6830bis-27 . . . . . . . . 40 - B.2. Changes to draft-ietf-lisp-rfc6830bis-26 . . . . . . . . 40 - B.3. Changes to draft-ietf-lisp-rfc6830bis-25 . . . . . . . . 40 - B.4. Changes to draft-ietf-lisp-rfc6830bis-24 . . . . . . . . 40 - B.5. Changes to draft-ietf-lisp-rfc6830bis-23 . . . . . . . . 41 - B.6. Changes to draft-ietf-lisp-rfc6830bis-22 . . . . . . . . 41 - B.7. Changes to draft-ietf-lisp-rfc6830bis-21 . . . . . . . . 41 - B.8. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 41 - B.9. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 41 - B.10. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 41 - B.11. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 41 - B.12. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 42 - B.13. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 42 - B.14. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 - B.15. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 42 - B.16. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 42 - B.17. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 42 - B.18. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 43 - B.19. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 43 - B.20. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 43 - B.21. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 44 - B.22. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 44 - B.23. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44 - B.24. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 44 - B.25. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 45 - B.26. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 45 - B.27. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 45 - B.28. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45 + B.2. Changes to draft-ietf-lisp-rfc6830bis-27 . . . . . . . . 40 + B.3. Changes to draft-ietf-lisp-rfc6830bis-26 . . . . . . . . 40 + B.4. Changes to draft-ietf-lisp-rfc6830bis-25 . . . . . . . . 41 + B.5. Changes to draft-ietf-lisp-rfc6830bis-24 . . . . . . . . 41 + B.6. Changes to draft-ietf-lisp-rfc6830bis-23 . . . . . . . . 41 + B.7. Changes to draft-ietf-lisp-rfc6830bis-22 . . . . . . . . 41 + B.8. Changes to draft-ietf-lisp-rfc6830bis-21 . . . . . . . . 41 + B.9. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 41 + B.10. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 41 + B.11. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 42 + B.12. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 42 + B.13. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 42 + B.14. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 42 + B.15. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 + B.16. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 42 + B.17. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 43 + B.18. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 43 + B.19. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 43 + B.20. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 43 + B.21. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 44 + B.22. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 44 + B.23. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 44 + B.24. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44 + B.25. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 45 + B.26. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 45 + B.27. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 45 + B.28. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 45 + B.29. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP encapsulation uses a dynamic form of tunneling where no static provisioning is required or necessary. LISP is an overlay protocol that separates control from Data-Plane, - this document specifies the Data-Plane, how LISP-capable routers - (Tunnel Routers) exchange packets by encapsulating them to the - appropriate location. Tunnel routers are equipped with a cache, + this document specifies the Data-Plane as well as how LISP-capable + routers (Tunnel Routers) exchange packets by encapsulating them to + the appropriate location. Tunnel routers are equipped with a cache, called Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache is populated using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP does not require changes to either the host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the @@ -194,61 +196,49 @@ 3. Definition of Terms Address Family Identifier (AFI): AFI is a term used to describe an address encoding in a packet. An address family that pertains to addresses found in Data-Plane headers. See [AFN] and [RFC3232] for details. An AFI value of 0 used in this specification indicates an unspecified encoded address where the length of the address is 0 octets following the 16-bit AFI value of 0. - Anycast Address: Anycast Address is a term used in this document to - 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 - anycast address in each of their own address spaces. + Anycast Address: Anycast Address refers to the same IPv4 or IPv6 + address configured and used on multiple systems at the same time. + An EID or RLOC can be an anycast address in each of their own + address spaces. Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an end-system represented by an EID. - Data-Probe: A Data-Probe is a LISP-encapsulated data packet where - the inner-header destination address equals the outer-header - destination address used to trigger a Map-Reply by a decapsulating - ETR. In addition, the original packet is decapsulated and - delivered to the destination host if the destination EID is in the - EID-Prefix range configured on the ETR. Otherwise, the packet is - discarded. A Data-Probe is used in some of the mapping database - designs to "probe" or request a Map-Reply from an ETR; in other - cases, Map-Requests are used. See each mapping database design - for details. When using Data-Probes, by sending Map-Requests on - the underlying routing system, EID-Prefixes must be advertised. - Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. EID-to-RLOC Database: The EID-to-RLOC Database is a distributed database that contains all known EID-Prefix-to-RLOC mappings. Each potential ETR typically contains a small piece of the database: the EID-to-RLOC mappings for the EID-Prefixes "behind" the router. These map to one of the router's own IP addresses that are routable on the underlay. Note that there MAY be - transient conditions when the EID-Prefix for the site and Locator- - Set for each EID-Prefix may not be the same on all ETRs. This has - no negative implications, since a partial set of Locators can be - used. + transient conditions when the EID-Prefix for the LISP site and + Locator-Set for each EID-Prefix may not be the same on all ETRs. + This has no negative implications, since a partial set of Locators + can be used. EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively static, and much more widely scoped to LISP nodes. EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are @@ -258,64 +248,58 @@ is to be associated with the larger EID-Prefix block. End-System: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP header when communicating outside of its routing domain. An end- system can be a host computer, a switch or router device, or any network appliance. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for - IPv6) value used in the source and destination address fields of - the first (most inner) LISP header of a packet. The host obtains - a destination EID the same way it obtains a destination address - today, for example, through a Domain Name System (DNS) [RFC1034] - lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. - The source EID is obtained via existing mechanisms used to set a - 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 - manner; this means, among other things, that it MUST be 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 used by a - host to refer to other hosts. Note that EID blocks MAY be - assigned in a hierarchical manner, independent of the network - topology, to facilitate scaling of the mapping database. In - addition, an EID block assigned to a site MAY have site-local - structure (subnetting) for routing within the site; this structure - is not visible to the underlay routing system. In theory, the bit - string that represents an EID for one device can represent an RLOC - for a different device. When used in discussions with other - Locator/ID separation proposals, a LISP EID will be called an - "LEID". Throughout this document, any references to "EID" refer - to an LEID. + IPv6) value that identifies a host. EIDs are generally only found + in the source and destination address fields of the first (most + inner) LISP header of a packet. The host obtains a destination + EID the same way it obtains a destination address today, for + example, through a Domain Name System (DNS) [RFC1034] lookup or + Session Initiation Protocol (SIP) [RFC3261] exchange. The source + EID is obtained via existing mechanisms used to set a 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 manner; + this means, among other things, that it MUST be 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 used by a host to + refer to other hosts. Note that EID blocks MAY be assigned in a + hierarchical manner, independent of the network topology, to + facilitate scaling of the mapping database. In addition, an EID + block assigned to a site MAY have site-local structure + (subnetting) for routing within the site; this structure is not + visible to the underlay routing system. In theory, the bit string + that represents an EID for one device can represent an RLOC for a + different device. When used in discussions with other Locator/ID + separation proposals, a LISP EID will be called an "LEID". + Throughout this document, any references to "EID" refer to an + LEID. Ingress Tunnel Router (ITR): An ITR is a router that resides in a LISP site. Packets sent by sources inside of the LISP site to destinations outside of the site are candidates for encapsulation by the ITR. The ITR treats the IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its routable RLOCs (in the RLOC space) in the source address field and the result of the mapping lookup in the destination address field. Note that this destination RLOC may be an intermediate, proxy device that has better knowledge of the EID-to-RLOC mapping closer to the destination EID. In general, an ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. - Specifically, when a service provider prepends a LISP header for - Traffic Engineering purposes, the router that does this is also - regarded as an ITR. The outer RLOC the ISP ITR uses can be based - on the outer destination address (the originating ITR's supplied - RLOC) or the inner destination address (the originating host's - supplied EID). - LISP Header: LISP header is a term used in this document to refer to the outer IPv4 or IPv6 header, a UDP header, and a LISP- specific 8-octet header that follow the UDP header and that an ITR prepends or an ETR strips. LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). LISP Site: LISP site is a set of routers in an edge network that are @@ -325,29 +309,20 @@ Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the LISP header. They are used by ITRs to inform ETRs about the up/ down status of all ETRs at the local site. These bits are used as a hint to convey up/down router status and not path reachability status. The LSBs can be verified by use of one of the Locator reachability algorithms described in Section 10. An ETR MUST rate-limit the action it takes when it detects changes in the Locator-Status-Bits. - Negative Mapping Entry: A negative mapping entry, also known as a - 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 - for the EID-to-RLOC entry is empty, one with an encoded Locator - count 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. There are a set of well-defined actions that are - encoded in a Negative Map-Reply. - 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 send packets to destinations at non-LISP sites. Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A PITR acts like an ITR but does so on behalf of non-LISP sites that send packets to destinations at LISP sites. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY @@ -379,28 +354,20 @@ or more RLOCs. Typically, RLOCs are numbered from blocks that are assigned to a site at each point to which it attaches to the underlay network; where the topology is defined by the connectivity of provider networks. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Server-side: Server-side is a term used in this document to indicate that a connection initiation attempt is being accepted for a destination EID. - TE-ETR: A TE-ETR is an ETR that is deployed in a service provider - network that strips an outer LISP header for Traffic Engineering - purposes. - - TE-ITR: A TE-ITR is an ITR that is deployed in a service provider - network that prepends an additional LISP header for Traffic - Engineering purposes. - xTR: An xTR is a reference to an ITR or ETR when direction of data flow is not part of the context description. "xTR" refers to the router that is the tunnel endpoint and is used synonymously with the term "Tunnel Router". For example, "An xTR can be located at the Customer Edge (CE) router" indicates both ITR and ETR functionality at the CE router. 4. Basic Overview One key concept of LISP is that end-systems operate the same way they @@ -528,59 +495,56 @@ 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. An A/AAAA record is returned. This address is the destination EID. The locally assigned address of 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 IP packet until it reaches a LISP ITR. 2. The LISP ITR must be able to map the destination EID to an RLOC - of one of the ETRs at the destination site. The specific method - used to do this is not described in this example. See - [I-D.ietf-lisp-rfc6833bis] for further information. - - 3. The ITR sends a LISP Map-Request as specified in - [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. + of one of the ETRs at the destination site. A method to do this + is to send a LISP Map-Request, as specified in + [I-D.ietf-lisp-rfc6833bis]. - 4. The mapping system helps forwarding the Map-Request to the + 3. The mapping system helps forwarding the Map-Request to the corresponding ETR. When the Map-Request arrives at one of the ETRs at the destination site, it will process the packet as a control message. - 5. The ETR looks at the destination EID of the Map-Request and + 4. The ETR looks at the destination EID of the Map-Request and matches it against the prefixes in the ETR's configured EID-to- 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, the Map-Request is dropped. Otherwise, a LISP Map-Reply is returned to the ITR. - 6. The ITR receives the Map-Reply message, parses the message, and + 5. The ITR receives the Map-Reply message, parses the message, and stores the mapping information 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. An ITR will manage its Map-Cache in such a way that optimizes for its resource constraints. - 7. Subsequent packets from host1.abc.example.com to + 6. Subsequent packets from host1.abc.example.com to host2.xyz.example.com will have a LISP header prepended by the ITR using the appropriate RLOC as the LISP header destination 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 the source site's hashing policy or the destination site's Locator-Set policy. - 8. The ETR receives these packets directly (since the destination + 7. The ETR receives these packets directly (since the destination address is one of its assigned IP addresses), checks the validity of the addresses, strips the LISP header, and forwards packets to the attached destination host. - 9. In order to defer the need for a mapping lookup in the reverse + 8. In order to defer the need for a mapping lookup in the reverse direction, an ETR can OPTIONALLY create a cache entry that maps the source EID (inner-header source IP address) to the source RLOC (outer-header source IP address) in a received LISP packet. Such a cache entry is termed a "glean mapping" and only contains a single RLOC for the EID in question. More complete information about additional RLOCs SHOULD be verified by sending a LISP Map- Request for that EID. Both the ITR and the ETR MAY also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details @@ -765,21 +731,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. 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.1 for more details. + 1, the N-bit MUST be 0. Refer to Section 13.2 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -824,63 +790,65 @@ 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 is set to 0 and is 8 bits when the I-bit is set to 1. When a Locator-Status-Bit is set to 1, the ITR is indicating to the ETR that the RLOC associated with the bit ordinal has up status. See Section 10 for details on how an ITR can determine the status of the ETRs at the same site. When a site has multiple EID-Prefixes that result in multiple mappings (where each could have a different Locator-Set), the Locator-Status-Bits setting in an encapsulated packet MUST reflect the mapping for the EID-Prefix - 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 - with that address, and the ETR is considered 'up'. + that the inner-header source EID address matches (longest-match). + If the LSB for an anycast Locator is set to 1, then there is at + least one RLOC with that address, and the ETR is considered 'up'. When doing ITR/PITR encapsulation: 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 Live' field. - o The outer-header 'Differentiated Services Code Point' (DSCP) field - (or the 'Traffic Class' field, in the case of IPv6) SHOULD be - copied from the inner-header DSCP field ('Traffic Class' field, in - the case of IPv6) to the outer-header. + o The outer-header IPv4 'Differentiated Services Code Point' (DSCP) + field or the 'Traffic Class' field, in the case of IPv6, SHOULD be + copied from the inner-header IPv4 DSCP field or 'Traffic Class' + field in the case of IPv6, to the outer-header. - 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 as specified - in [RFC6040]. + o The IPv4 'Explicit Congestion Notification' (ECN) field and bits 6 + and 7 of the IPv6 'Traffic Class' field requires special treatment + in order to avoid discarding indications of congestion as + specified in [RFC6040]. When doing ETR/PETR decapsulation: - o The inner-header 'Time to Live' field (or 'Hop Limit' field, in - the case of IPv6) MUST be copied from the outer-header 'Time to - 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 - perform this check can cause the Time to Live of the inner header - to increment across encapsulation/decapsulation cycles. This - check is also performed when doing initial encapsulation, when a - packet comes to an ITR or PITR destined for a LISP site. + o The inner-header IPv4 'Time to Live' field or 'Hop Limit' field in + the case of IPv6, MUST be copied from the outer-header 'Time to + Live'/'Hop Limit' field, when the 'Time to Live'/'Hop Limit' value + of the outer header is less than the 'Time to Live'/'Hop Limit' + value of the inner header. Failing to perform this check can + cause the 'Time to Live'/'Hop Limit' of the inner header to + increment across encapsulation/decapsulation cycles. This check + is also performed when doing initial encapsulation, when a packet + comes to an ITR or PITR destined for a LISP site. - o The outer-header 'Differentiated Services Code Point' (DSCP) field - (or the 'Traffic Class' field, in the case of IPv6) SHOULD be - copied from the outer-header DSCP field ('Traffic Class' field, in - the case of IPv6) to the inner-header. + o The outer-header IPv4 'Differentiated Services Code Point' (DSCP) + field or the 'Traffic Class' field in the case of IPv6, SHOULD be + copied from the outer-header IPv4 DSCP field or 'Traffic Class' + field in the case of IPv6, to the inner-header. - 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 as specified - in [RFC6040]. Note that implementations exist that copy the 'ECN' - field from the outer header to the inner header even though - [RFC6040] does not recommend this behavior. It is RECOMMENDED - that implementations change to support the behavior in [RFC6040]. + o The IPv4 'Explicit Congestion Notification' (ECN) field and bits 6 + and 7 of the IPv6 'Traffic Class' field, requires special + treatment in order to avoid discarding indications of congestion + as specified in [RFC6040]. Note that implementations exist that + copy the 'ECN' field from the outer header to the inner header + even though [RFC6040] does not recommend this behavior. It is + RECOMMENDED that implementations change to support the behavior in + [RFC6040]. 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 new outer header will carry the same Time to Live as the old outer header minus 1. Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to @@ -986,22 +954,22 @@ When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling - An ITR stateful solution to handle MTU issues is described as follows - and was first introduced in [OPENLISP]: + An ITR stateful solution to handle MTU issues is described as + follows: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an ICMPv6 "Packet Too Big" message or an ICMPv4 Unreachable/ Fragmentation-Needed to the ITR, respectively. The ITR will @@ -1037,20 +1006,23 @@ to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. 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 details. + Participants within a LISP deployment must agree on the meaning of + Instance ID values. + 9. Routing Locator Selection The Map-Cache contains the state used by ITRs and PITRs to encapsulate packets. When an ITR/PITR receives a packet from inside 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). The lookup returns a single Locator-Set containing a list of RLOCs corresponding to the EID's topological location. Each RLOC in the Locator-Set is associated with a 'Priority' and 'Weight', this information is used to select the RLOC to encapsulate. @@ -1081,52 +1053,48 @@ list are unreachable. o The server-side sets a Weight of zero for the RLOC subset list. In this case, the client-side can choose how the traffic load is spread across the subset list. See Section 12 for details on load-sharing mechanisms. Control is shared by the server-side determining the list and the client-side determining load distribution. Again, the client can use alternative RLOCs if the server-provided list of RLOCs is unreachable. - 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 - Map-Requests, it gleans RLOCs from the client-side ITR, giving the - client-side ITR responsibility for bidirectional RLOC reachability - and preferability. Server-side ETR gleaning of the client-side - ITR RLOC is done by caching the inner-header source EID and the - outer-header source RLOC of received packets. The client-side ITR - controls how traffic is returned and can alternate using an outer- - header source RLOC, which then can be added to the list the - server-side ETR uses to return traffic. Since no Priority or - Weights are provided using this method, the server-side ETR MUST - assume that each client-side ITR RLOC uses the same best Priority - with a Weight of zero. In addition, since EID-Prefix encoding - cannot be conveyed in data packets, the EID-to-RLOC Cache on - Tunnel Routers can grow to be very large. - - Instead of using the Map-Cache or mapping system, RLOC information - MAY be gleaned from received tunneled packets or Map-Request - messages. A "gleaned" Map-Cache entry, one learned from the source - RLOC of a received encapsulated packet, is only stored and used for a - few seconds, pending verification. Verification is performed by - sending a Map-Request to the source EID (the inner-header IP source - address) of the received encapsulated packet. A reply to this - "verifying Map-Request" is used to fully populate the Map-Cache entry - for the "gleaned" EID and is stored and used for the time indicated - from the 'TTL' field of a received Map-Reply. When a verified Map- - Cache entry is stored, data gleaning no longer occurs for subsequent - packets that have a source EID that matches the EID-Prefix of the - verified entry. This "gleaning" mechanism SHOULD NOT be used over - the public Internet and SHOULD only be used in trusted and closed - deployments. Refer to Section 16 for security issues regarding this - mechanism. + o Either side (more likely the server-side ETR) decides to "glean" + the RLOCs. For example, if the server-side ETR gleans RLOCs, then + the client-side ITR gives the client-side ITR responsibility for + bidirectional RLOC reachability and preferability. Server-side + ETR gleaning of the client-side ITR RLOC is done by caching the + inner-header source EID and the outer-header source RLOC of + received packets. The client-side ITR controls how traffic is + returned and can alternate using an outer-header source RLOC, + which then can be added to the list the server-side ETR uses to + return traffic. Since no Priority or Weights are provided using + this method, the server-side ETR MUST assume that each client-side + ITR RLOC uses the same best Priority with a Weight of zero. In + addition, since EID-Prefix encoding cannot be conveyed in data + packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be + very large. Gleaning has several important considerations. A + "gleaned" Map-Cache entry is only stored and used for a few + seconds, pending verification. Verification is performed by + sending a Map-Request to the source EID (the inner-header IP + source address) of the received encapsulated packet. A reply to + this "verifying Map-Request" is used to fully populate the Map- + Cache entry for the "gleaned" EID and is stored and used for the + time indicated from the 'TTL' field of a received Map-Reply. When + a verified Map- Cache entry is stored, data gleaning no longer + occurs for subsequent packets that have a source EID that matches + the EID-Prefix of the verified entry. This "gleaning" mechanism + SHOULD NOT be used over the public Internet and SHOULD only be + used in trusted and closed deployments. Refer to Section 16 for + security issues regarding this mechanism. RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be reachable when the R-bit [I-D.ietf-lisp-rfc6833bis] 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 RLOC. Neither the information contained in a Map-Reply nor that stored in the mapping database system provides reachability information for RLOCs. Note that reachability is not part of the mapping system and is determined using one or more of the Routing Locator reachability algorithms described in the next section. @@ -1138,21 +1106,22 @@ reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. 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 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 RLOC. 2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely to be - reachable. + reachable. Please note that in some scenarios the RLOC from the + outer header can be an spoofable field. 3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability algorithms described in this section. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: @@ -1173,63 +1142,65 @@ address is configured on a loopback interface. RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. - When an ETR decapsulates a packet, it will check for any change in - the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the - ETR, if acting also as an ITR, will refrain from encapsulating - packets to an RLOC that is indicated as down. It will only resume - using that RLOC if the corresponding Locator-Status-Bit returns to a - value of 1. Locator-Status-Bits are associated with a Locator-Set - per EID-Prefix. Therefore, when a Locator becomes unreachable, the - Locator-Status-Bit that corresponds to that Locator's position in the - list returned by the last Map-Reply will be set to zero for that - particular EID-Prefix. + When an xTR decides to use 'Locator-Status-Bits' to affect + reachability information, it acts as follows: ETRs decapsulating a + packet will check for any change in the 'Locator-Status-Bits' field. + When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will + refrain from encapsulating packets to an RLOC that is indicated as + down. It will only resume using that RLOC if the corresponding + Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are + associated with a Locator-Set per EID-Prefix. Therefore, when a + Locator becomes unreachable, the Locator-Status-Bit that corresponds + to that Locator's position in the list returned by the last Map-Reply + will be set to zero for that particular EID-Prefix. Locator-Status-Bits SHOULD NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. In addition Locator-Status-Bits SHOULD be coupled with Map-Versioning - (Section 13.1) to prevent race conditions. Refer to Section 16 for - security issues regarding this mechanism. + (Section 13.2) to prevent race conditions where Locator-Status-Bits + are interpreted as referring to different RLOCs than intended. Refer + to Section 16 for security issues regarding this mechanism. If an ITR encapsulates a packet to an ETR and the packet is received and decapsulated by the ETR, it is implied but not confirmed by the ITR that the ETR's RLOC is reachable. In 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 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 unreachable. Instead, it MUST use an alternate mechanism to determine reachability. - The security considerations of Section 16 related with data-plane + The security considerations of Section 16 related to data-plane reachability applies to the data-plane RLOC reachability mechanisms described in this section. 10.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a Data-Plane mechanism called "nonce echoing" can be used 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 nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR is an xTR (co-located as an ITR), - it next sends a data packet to the ITR (when it is an xTR co-located + it then sends a data packet to the ITR (when it is an xTR co-located as an ETR), 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 path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the @@ -1347,63 +1318,53 @@ 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- 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 which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. - This section defines a Data-Plane mechanism for updating EID-to-RLOC - mappings. Additionally, the Solicit-Map Request (SMR) Control-Plane - updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis]. + This section defines two Data-Plane mechanism for updating EID-to- + RLOC mappings. Additionally, the Solicit-Map Request (SMR) Control- + Plane updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis]. - 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 - 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, - 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 - old mapping but detects bits set in the Locator-Status-Bits that - correspond to Locators beyond the list it has cached, it simply - ignores them. However, this can only happen for locator addresses - that are lexicographically greater than the locator addresses in the - existing Locator-Set. +13.1. Locator-Status-Bits - When a Locator record is inserted in the middle of a Locator-Set, to - maintain lexicographic order, SMR procedure - [I-D.ietf-lisp-rfc6833bis] is used to inform ITRs and PITRs of the - new Locator-Status-Bit mappings. + Locator-Status-Bits (LSB) can also be used to keep track of the + Locator status (up or down) when EID-to-RLOC mappings are changing. + When LSB are used in a LISP deployment, all LISP tunnel routers MUST + implement both ITR and ETR capabilities (therefore all tunnel routers + are effectively xTRs). In this section the term "source xTR" is used + to refer to the xTR setting the LSB and "destination xTR" is used to + refer to the xTR receiving the LSB. The procedure is as follows: - When a Locator record is removed from a Locator-Set, ITRs that have - the mapping cached will not use the removed Locator because the xTRs - will set the Locator-Status-Bit to 0. So, even if the Locator is in - the list, it will not be used. For new mapping requests, the xTRs - can set the Locator AFI to 0 (indicating an unspecified address), as - well as setting the corresponding Locator-Status-Bit to 0. This - forces ITRs with old or new mappings to avoid using the removed - Locator. + First, when a Locator record is added or removed from the Locator- + Set, the source xTR will signal this by sending a Solicit-Map Request + (SMR) Control-Plane message [I-D.ietf-lisp-rfc6833bis] to the + destination xTR. At this point the source xTR MUST NOT use LSB + (L-bit = 0) since the destination xTR site has outdated information. + The source xTR will setup a 'use-LSB' timer. - 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 - records appended to the Locator-Set. At some point, it would be - useful to compact the Locator-Set so the Locator-Status-Bit settings - can be efficiently packed. + Second and as defined in [I-D.ietf-lisp-rfc6833bis], upon reception + of the SMR message the destination xTR will retrieve the updated EID- + to-RLOC mappings by sending a Map-Request. - We propose here a Data-Plane mechanism (Map-Versioning specified in - [I-D.ietf-lisp-6834bis]) to update the contents of EID-to-RLOC - mappings. Please note that in addition the Solicit-Map Request - (specified in [I-D.ietf-lisp-rfc6833bis]) is a Control-Plane - mechanisms that can be used to update EID-to-RLOC mappings. + And third, when the 'use-LSB' timer expires, the source xTR can use + again LSB with the destination xTR to signal the Locator status (up + or down). The specific value for the 'use-LSB' timer depends on the + LISP deployment, the 'use-LSB' timer needs to be large enough for the + destination xTR to retreive the updated EID-to-RLOC mappings. A + RECOMMENDED value for the 'use-LSB' timer is 5 minutes. -13.1. Database Map-Versioning +13.2. Database Map-Versioning 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 ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and @@ -1422,20 +1383,27 @@ values that are greater are considered to be more recent. A value of 0 for the Source Map-Version Number or the Destination Map-Version Number conveys no versioning information, and an ITR does no comparison with previously received Map-Version Numbers. A Map-Version Number can be included in Map-Register messages as well. This is a good way for the Map-Server to assure that all ETRs for a site registering to it will be synchronized according to Map- Version Number. + Map-Version requires that ETRs within the LISP site are synchronized + with respect to the Map-Version Number, EID-prefix and the set and + status (up/down) of the RLOCs. The use of Map-Versioning without + proper synzhronization may cause traffic disruption. The + synchronization protocol is out-of-the-scope of this document, but + MUST keep ETRs synchronized within a 1 minute window. + Map-Versioning SHOULD NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. Refer to Section 16 for security issues regarding this mechanism. See [I-D.ietf-lisp-6834bis] for a more detailed analysis and description of Database Map-Versioning. 14. Multicast Considerations A multicast group address, as defined in the original Internet @@ -1450,23 +1418,23 @@ to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, can use the same group address as the destination Routing Locator, use a multicast or unicast Routing Locator obtained from a Mapping System lookup, or use other means to determine the group address mapping. With respect to the source Routing Locator address, the ITR prepends - its own IP address as the source address of the outer IP header. - Just like it would if the destination EID was a unicast address. - This source Routing Locator address, like any other Routing Locator + its own IP address as the source address of the outer IP header, just + like it would if the destination EID was a unicast address. This + source Routing Locator address, like any other Routing Locator address, MUST be routable on the underlay. There are two approaches for LISP-Multicast, one that uses native multicast routing in the underlay with no support from the Mapping System and the other that uses only unicast routing in the underlay with support from the Mapping System. See [RFC6831] and [RFC8378], respectively, for details. Details for LISP-Multicast and interworking with non-LISP sites are described in [RFC6831] and [RFC6832]. @@ -1544,21 +1512,23 @@ 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 peering xTR uses LISP Control-Plane signaling message to retrieve a fresh mapping. This can be used by an attacker to forge the map- versioning field of a LISP encapsulated header and force an excessive amount of signaling between xTRs that may overload them. Locator-Status-Bits, echo-nonce and map-versioning SHOULD NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. In addition Locator-Status-Bits SHOULD be - coupled with map-versioning to prevent race conditions. + coupled with map-versioning to prevent race conditions where Locator- + Status-Bits are interpreted as referring to different RLOCs than + intended. LISP implementations and deployments which permit outer header fragments of IPv6 LISP encapsulated packets as a means of dealing with MTU issues should also use implementation techniques in ETRs to prevent this from being a DoS attack vector. Limits on the number of fragments awaiting reassembly at an ETR, RTR, or PETR, and the rate of admitting such fragments may be used. 17. Network Management Considerations @@ -1607,27 +1577,27 @@ lisp-data 4341 udp LISP Data Packets 20. References 20.1. Normative References [I-D.ietf-lisp-6834bis] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", draft-ietf- - lisp-6834bis-03 (work in progress), February 2019. + lisp-6834bis-04 (work in progress), August 2019. [I-D.ietf-lisp-rfc6833bis] - Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, - "Locator/ID Separation Protocol (LISP) Control-Plane", - draft-ietf-lisp-rfc6833bis-24 (work in progress), February - 2019. + Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- + Aparicio, "Locator/ID Separation Protocol (LISP) Control- + Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), + June 2019. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1687,24 +1657,20 @@ Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-04 (work in progress), May 2019. - [OPENLISP] - Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP - Implementation Report", Work in Progress, July 2008. - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. @@ -1849,206 +1815,216 @@ Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The contributions they offered greatly added to the security, scale, and robustness of the LISP architecture and protocols. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-rfc6830bis-27 + o Posted November 2019. + + o Fixed how LSB behave in the presence of new/removed locators. + + o Added ETR synchronization requirements when using Map-Versioning. + + o Fixed a large set of minor comments and edits. + +B.2. Changes to draft-ietf-lisp-rfc6830bis-27 + o Posted April 2019 post telechat. o Made editorial corrections per Warren's suggestions. o Put in suggested text from Luigi that Mirja agreed with. o LSB, Echo-Nonce and Map-Versioning SHOULD be only used in closed environments. o Removed paragraph stating that Instance-ID can be 32-bit in the control-plane. o 6831/8378 are now normative. o Rewritten Security Considerations according to the changes. o Stated that LSB SHOULD be coupled with Map-Versioning. -B.2. Changes to draft-ietf-lisp-rfc6830bis-26 +B.3. Changes to draft-ietf-lisp-rfc6830bis-26 o Posted late October 2018. o Changed description about "reserved" bits to state "reserved and unassigned". -B.3. Changes to draft-ietf-lisp-rfc6830bis-25 +B.4. Changes to draft-ietf-lisp-rfc6830bis-25 o Posted mid October 2018. o Added more to the Security Considerations section with discussion about echo-nonce attacks. -B.4. Changes to draft-ietf-lisp-rfc6830bis-24 +B.5. Changes to draft-ietf-lisp-rfc6830bis-24 o Posted mid October 2018. o Final editorial changes for Eric and Ben. -B.5. Changes to draft-ietf-lisp-rfc6830bis-23 +B.6. Changes to draft-ietf-lisp-rfc6830bis-23 o Posted early October 2018. o Added an applicability statement in section 1 to address security concerns from Telechat. -B.6. Changes to draft-ietf-lisp-rfc6830bis-22 +B.7. Changes to draft-ietf-lisp-rfc6830bis-22 o Posted early October 2018. o Changes to reflect comments post Telechat. -B.7. Changes to draft-ietf-lisp-rfc6830bis-21 +B.8. Changes to draft-ietf-lisp-rfc6830bis-21 o Posted late-September 2018. o Changes to reflect comments from Sep 27th Telechat. -B.8. Changes to draft-ietf-lisp-rfc6830bis-20 +B.9. Changes to draft-ietf-lisp-rfc6830bis-20 o Posted late-September 2018. o Fix old reference to RFC3168, changed to RFC6040. -B.9. Changes to draft-ietf-lisp-rfc6830bis-19 +B.10. Changes to draft-ietf-lisp-rfc6830bis-19 o Posted late-September 2018. o More editorial changes. -B.10. Changes to draft-ietf-lisp-rfc6830bis-18 +B.11. Changes to draft-ietf-lisp-rfc6830bis-18 o Posted mid-September 2018. o Changes to reflect comments from Secdir review (Mirja). -B.11. Changes to draft-ietf-lisp-rfc6830bis-17 +B.12. Changes to draft-ietf-lisp-rfc6830bis-17 o Posted September 2018. o Indicate in the "Changes since RFC 6830" section why the document has been shortened in length. o Make reference to RFC 8085 about UDP congestion control. o More editorial changes from multiple IESG reviews. -B.12. Changes to draft-ietf-lisp-rfc6830bis-16 +B.13. Changes to draft-ietf-lisp-rfc6830bis-16 o Posted late August 2018. o Distinguish the message type names between ICMP for IPv4 and ICMP for IPv6 for handling MTU issues. -B.13. Changes to draft-ietf-lisp-rfc6830bis-15 +B.14. Changes to draft-ietf-lisp-rfc6830bis-15 o Posted August 2018. o Final editorial changes before RFC submission for Proposed Standard. o Added section "Changes since RFC 6830" so implementers are informed of any changes since the last RFC publication. -B.14. Changes to draft-ietf-lisp-rfc6830bis-14 +B.15. Changes to draft-ietf-lisp-rfc6830bis-14 o Posted July 2018 IETF week. o Put obsolete of RFC 6830 in Intro section in addition to abstract. -B.15. Changes to draft-ietf-lisp-rfc6830bis-13 +B.16. Changes to draft-ietf-lisp-rfc6830bis-13 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.16. Changes to draft-ietf-lisp-rfc6830bis-12 +B.17. Changes to draft-ietf-lisp-rfc6830bis-12 o Posted July 2018. o Fixed Luigi editorial comments to ready draft for RFC status. -B.17. Changes to draft-ietf-lisp-rfc6830bis-11 +B.18. Changes to draft-ietf-lisp-rfc6830bis-11 o Posted March 2018. o Removed sections 16, 17 and 18 (Mobility, Deployment and Traceroute considerations). This text must be placed in a new OAM document. -B.18. Changes to draft-ietf-lisp-rfc6830bis-10 +B.19. Changes to draft-ietf-lisp-rfc6830bis-10 o Posted March 2018. o Updated section 'Router Locator Selection' stating that the Data- Plane MUST follow what's stored in the Map-Cache (priorities and weights). o Section 'Routing Locator Reachability': Removed bullet point 2 (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response) and RLOC probing o Removed 'Solicit-Map Request'. -B.19. Changes to draft-ietf-lisp-rfc6830bis-09 +B.20. 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.20. Changes to draft-ietf-lisp-rfc6830bis-08 +B.21. Changes to draft-ietf-lisp-rfc6830bis-08 o Posted January 2018. o Remove references to research work for any protocol mechanisms. o Document scanned to make sure it is RFC 2119 compliant. o Made changes to reflect comments from document WG shepherd Luigi Iannone. o Ran IDNITs on the document. -B.21. Changes to draft-ietf-lisp-rfc6830bis-07 +B.22. Changes to draft-ietf-lisp-rfc6830bis-07 o Posted November 2017. o Rephrase how Instance-IDs are used and don't refer to [RFC1918] addresses. -B.22. Changes to draft-ietf-lisp-rfc6830bis-06 +B.23. Changes to draft-ietf-lisp-rfc6830bis-06 o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". @@ -2057,61 +2033,61 @@ o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addresses can be used. -B.23. Changes to draft-ietf-lisp-rfc6830bis-05 +B.24. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Re-encapsulating Tunnel Router is an RTR. -B.24. Changes to draft-ietf-lisp-rfc6830bis-04 +B.25. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. -B.25. Changes to draft-ietf-lisp-rfc6830bis-03 +B.26. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. -B.26. Changes to draft-ietf-lisp-rfc6830bis-02 +B.27. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.27. Changes to draft-ietf-lisp-rfc6830bis-01 +B.28. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. o Remove references to "experimental". -B.28. Changes to draft-ietf-lisp-rfc6830bis-00 +B.29. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Dino Farinacci lispers.net