--- 1/draft-ietf-lisp-rfc6830bis-26.txt 2019-06-16 15:13:18.607500698 -0700 +++ 2/draft-ietf-lisp-rfc6830bis-27.txt 2019-06-16 15:13:18.707503222 -0700 @@ -1,22 +1,25 @@ Network Working Group D. Farinacci -Internet-Draft V. Fuller -Obsoletes: 6830 (if approved) D. Meyer -Intended status: Standards Track D. Lewis -Expires: May 8, 2019 Cisco Systems +Internet-Draft lispers.net +Obsoletes: 6830 (if approved) V. Fuller +Intended status: Standards Track vaf.net Internet Consulting +Expires: December 18, 2019 D. Meyer + 1-4-5.net + D. Lewis + Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - November 4, 2018 + June 16, 2019 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-26 + draft-ietf-lisp-rfc6830bis-27 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. @@ -35,25 +38,25 @@ 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 May 8, 2019. + This Internet-Draft will expire on December 18, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -64,71 +67,72 @@ 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 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 . . . . . . . . . . . . . . . . . 20 + 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 - 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 + 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 - 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 25 + 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . 31 + 15. Router Performance Considerations . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 17. Network Management Considerations . . . . . . . . . . . . . . 33 - 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 + 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 34 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 34 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 20.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 20.2. Informative References . . . . . . . . . . . . . . . . . 35 + 20.2. Informative References . . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 40 - B.1. Changes to draft-ietf-lisp-rfc6830bis-26 . . . . . . . . 40 - B.2. Changes to draft-ietf-lisp-rfc6830bis-25 . . . . . . . . 40 - B.3. Changes to draft-ietf-lisp-rfc6830bis-24 . . . . . . . . 40 - B.4. Changes to draft-ietf-lisp-rfc6830bis-23 . . . . . . . . 40 - B.5. Changes to draft-ietf-lisp-rfc6830bis-22 . . . . . . . . 40 - B.6. Changes to draft-ietf-lisp-rfc6830bis-21 . . . . . . . . 40 - B.7. Changes to draft-ietf-lisp-rfc6830bis-20 . . . . . . . . 41 - B.8. Changes to draft-ietf-lisp-rfc6830bis-19 . . . . . . . . 41 - B.9. Changes to draft-ietf-lisp-rfc6830bis-18 . . . . . . . . 41 - B.10. Changes to draft-ietf-lisp-rfc6830bis-17 . . . . . . . . 41 - B.11. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 41 - B.12. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 41 - B.13. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 42 - B.14. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 42 - B.15. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 42 - B.16. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 42 - B.17. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 42 - B.18. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 43 - B.19. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 43 - B.20. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 43 - B.21. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 43 - B.22. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 44 - B.23. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 44 - B.24. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 44 - B.25. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 44 - B.26. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 44 - B.27. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 45 + 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 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 @@ -141,21 +145,21 @@ 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, 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 host protocol stack or to + 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 IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). This document specifies the LISP Data-Plane encapsulation and other LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] @@ -221,39 +225,38 @@ Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. In general, an ETR receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well. - EID-to-RLOC Database: The EID-to-RLOC Database is a global - distributed database that contains all known EID-Prefix-to-RLOC - mappings. Each potential ETR typically contains a small piece of - the database: the EID-to-RLOC mappings for the EID-Prefixes - "behind" the router. These map to one of the router's own 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. + 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. EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is generally short-lived, on-demand table in an ITR that stores, tracks, and is responsible for timing out and otherwise validating EID-to-RLOC mappings. This cache is distinct from the full "database" of EID- to-RLOC mappings; it is dynamic, local to the ITR(s), and relatively small, while the database is distributed, relatively - static, and much more global in scope to LISP nodes. + static, and much more widely scoped to LISP nodes. EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are allocated to a site by an address allocation authority. EID- Prefixes are associated with a set of RLOC addresses. EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. End-System: An end-system is an IPv4 or IPv6 device that originates packets with a single IPv4 or IPv6 header. The end-system supplies an EID value for the destination address field of the IP @@ -263,25 +266,25 @@ 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 globally - 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 + 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. @@ -544,26 +547,25 @@ 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 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 (to - check for format validity), 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. + 6. 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 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 @@ -839,102 +841,87 @@ 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 '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 [RFC6040]. - ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner - header to the outer header. Re-encapsulation MUST copy the 2-bit - 'ECN' field from the stripped outer header to the new outer - header. + 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 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 '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 [RFC6040]. If - the 'ECN' field contains a congestion indication codepoint (the - value is '11', the Congestion Experienced (CE) codepoint), then - ETR decapsulation MUST copy the 2-bit 'ECN' field from the - stripped outer header to the surviving inner header that is used - to forward the packet beyond the ETR. These requirements preserve - CE indications when a packet that uses ECN traverses a LISP tunnel - and becomes marked with a CE indication due to congestion between - the tunnel endpoints. Implementations exist that copy the 'ECN' + 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 misconfiguration. - The Explicit Congestion Notification ('ECN') field occupies bits 6 - and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic - Class' field [RFC6040]. The 'ECN' field requires special treatment - in order to avoid discarding indications of congestion [RFC6040]. An - ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner - header to the outer header. Re-encapsulation MUST copy the 2-bit - 'ECN' field from the stripped outer header to the new outer header. - If the 'ECN' field contains a congestion indication codepoint (the - value is '11', the Congestion Experienced (CE) codepoint), then ETR/ - PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped - outer header to the surviving inner header that is used to forward - the packet beyond the ETR. These requirements preserve CE - indications when a packet that uses ECN traverses a LISP tunnel and - becomes marked with a CE indication due to congestion between the - tunnel endpoints. + Some xTRs and PxTRs performs re-encapsulation operations and need to + treat the 'Explicit Congestion Notification' (ECN) in a special way. + Because the re-encapsulation operation is a sequence of two + operations, namely a decapsulation followed by an encapsulation, the + ECN bits MUST be treated as described above for these two operations. 6. LISP EID-to-RLOC Map-Cache ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- RLOC Map-Cache, that contains mappings from EID-prefixes to locator sets. The cache is used to encapsulate packets from the EID space to the corresponding RLOC network attachment point. 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 EID is done to the Map-Cache. When the lookup succeeds, the Locator-Set retrieved from the Map- 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 - the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. The - mapping is then stored in the local Map-Cache to forward subsequent - packets addressed to the same EID-prefix. + the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. While + the mapping is being retrieved, the ITR/PITR can either drop or + buffer the packets. This document does not have specific + recommendations about the action to be taken. It is up to the + deployer to consider whether or not it is desirable to buffer packets + and deploy a LISP implementation that offers the desired behaviour. + Once the mapping is resolved it is then stored in the local Map-Cache + to forward subsequent packets addressed to the same EID-prefix. 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 with more current information, see Section 13 for further information on this. Finally, the Map-Cache also contains reachability information about EIDs and RLOCs, and uses LISP reachability information mechanisms to determine the reachability of RLOCs, see Section 10 for the specific mechanisms. 7. Dealing with Large Encapsulated Packets @@ -955,21 +942,23 @@ An ITR stateless solution to handle MTU issues is described as follows: 1. Define H to be the size, in octets, of the outer header an ITR prepends to a packet. This includes the UDP and LISP header lengths. 2. Define L to be the size, in octets, of the maximum-sized packet an ITR can send to an ETR without the need for the ITR or any - intermediate routers to fragment the packet. + intermediate routers to fragment the packet. The network + administrator of the LISP deployment has to determine what is the + suitable value of L so to make sure that no MTU issues arise. 3. Define an architectural constant S for the maximum size of a packet, in octets, an ITR MUST receive from the source so the effective MTU can be met. That is, L = S + H. When an ITR receives a packet from a site-facing interface and adds H octets worth of encapsulation to yield a packet size greater than L octets (meaning the received packet size was greater than S octets from the source), it resolves the MTU issue by first splitting the original packet into 2 equal-sized fragments. A LISP header is then @@ -982,23 +971,24 @@ then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior MUST be performed by the ITR only when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the - packet when the size is greater than L and send an ICMPv4 ICMP - Unreachable/Fragmentation-Needed or ICMPv6 "Packet Too Big" message - to the source with a value of S, where S is (L - H). + packet when the size (adding in the size of the encapsulation header) + is greater than L and send an ICMPv4 ICMP Unreachable/Fragmentation- + Needed or ICMPv6 "Packet Too Big" message to the source with a value + of S, where S is (L - H). 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 @@ -1047,26 +1037,20 @@ 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. - 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 - 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 - bits don't overlap among xTRs. - 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. @@ -1091,22 +1075,23 @@ splitting across its members. The client-side can use RLOCs outside of the subset list if it determines that the subset list is unreachable (unless RLOCs are set to a Priority of 255). Some sharing of control exists: the server-side determines the destination RLOC list and load distribution while the client-side has the option of using alternatives to this list if RLOCs in the 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. Control is shared by the server- - side determining the list and the client-side determining load + 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 @@ -1124,22 +1109,24 @@ 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 is OPTIONAL, refer to - Section 16 for security issues regarding this mechanism. + 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. @@ -1195,22 +1182,27 @@ 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. Refer to Section 16 for security related - issues regarding Locator-Status-Bits. + 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. 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. @@ -1265,20 +1257,28 @@ unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- probe Map-Reply message. + Many implementations default to not advertising they are echo-nonce + capable in Map-Reply messages and so RLOC-probing tends to be used + for RLOC reachability. + + The echo-nonce 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. + 11. EID Reachability within a LISP Site A site MAY be multihomed using two or more ETRs. The hosts and infrastructure within a site will be addressed using one or more EID- Prefixes that are mapped to the RLOCs of the relevant ETRs in the mapping system. One possible failure mode is for an ETR to lose reachability to one or more of the EID-Prefixes within its own site. When this occurs when the ETR sends Map-Replies, it can clear the R-bit associated with its own Locator. And when the ETR is also an ITR, it can clear its Locator-Status-Bit in the encapsulation data @@ -1316,30 +1316,32 @@ 2. Take the hash value and divide it by the number of Locators stored in the Locator-Set for the EID-to-RLOC mapping. 3. The remainder will yield a value of 0 to "number of Locators minus 1". Use the remainder to select the Locator in the Locator-Set. The specific hash algorithm the ITR uses for load-sharing is out of scope for this document and does not prevent interoperability. - Note that when a packet is LISP encapsulated, the source port number - in the outer UDP header needs to be set. Selecting a hashed value - allows core routers that are attached to Link Aggregation Groups - (LAGs) to load-split the encapsulated packets across member links of - such LAGs. Otherwise, core routers would see a single flow, since - packets have a source address of the ITR, for packets that are - originated by different EIDs at the source site. A suggested setting - for the source port number computed by an ITR is a 5-tuple hash - function on the inner header, as described above. The source port - SHOULD be the same for all packets belonging to the same flow. + The Source port SHOULD be the same for all packets belonging to the + same flow. Also note that when a packet is LISP encapsulated, the + source port number in the outer UDP header needs to be set. + Selecting a hashed value allows core routers that are attached to + Link Aggregation Groups (LAGs) to load-split the encapsulated packets + across member links of such LAGs. Otherwise, core routers would see + a single flow, since packets have a source address of the ITR, for + packets that are originated by different EIDs at the source site. A + suggested setting for the source port number computed by an ITR is a + 5-tuple hash function on the inner header, as described above. The + source port SHOULD be the same for all packets belonging to the same + flow. Many core router implementations use a 5-tuple hash to decide how to balance packet load across members of a LAG. The 5-tuple hash includes the source and destination addresses of the packet and the source and destination ports when the protocol number in the packet is TCP or UDP. For this reason, UDP encoding is used for LISP encapsulation. 13. Changing the Contents of EID-to-RLOC Mappings @@ -1420,20 +1422,24 @@ 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-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 architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, @@ -1491,69 +1497,75 @@ 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 routing table can be used to find EID-to-RLOC mappings. For performance issues related to Map-Cache management, see Section 16. 16. Security Considerations - A complete LISP threat analysis can be found in [RFC7835]. In what - follows we highlight security considerations that apply when LISP is - deployed in environments such as those specified in Section 1.1. + In what follows we highlight security considerations that apply when + LISP is deployed in environments such as those specified in + Section 1.1. The optional mechanisms of gleaning is offered to directly obtain a mapping from the LISP encapsulated packets. Specifically, an xTR can learn the EID-to-RLOC mapping by inspecting the source RLOC and source EID of an encapsulated packet, and insert this new mapping 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 the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim's RLOC, potentially overloading it. The LISP Data-Plane defines several mechanisms to monitor RLOC Data- Plane reachability, in this context Locator-Status Bits, Nonce- Present and Echo-Nonce bits of the LISP encapsulation header can be manipulated by an attacker to mount a DoS attack. An off-path attacker able to spoof the RLOC and/or nonce of a victim's xTR can manipulate such mechanisms to declare false information about the RLOC's reachability status. - As an exmple of such attacks an off-path attacker can exploit the + For example of such attacks, an off-path attacker can exploit the echo-nonce mechanism by sending data packets to an ITR with a random nonce from an ETR's spoofed RLOC. Note the attacker must guess a valid nonce the ITR is requesting to be echoed within a small window of time. The goal is to convince the ITR that the ETR's RLOC is reachable even when it may not be reachable. If the attack is successful, the ITR believes the wrong reachability status of the ETR's RLOC until RLOC-probing detects the correct status. This time frame is on the order of 10s of seconds. This specific attack can be mitigated by preventing RLOC spoofing in the network by deploying uRPF BCP 38 [RFC2827]. In addition and in order to exploit this vulnerability, the off-path attacker must send echo-nonce packets at high rate. If the nonces have never been requested by the ITR, it - can protect itself from erroneious reachability attacks. + can protect itself from erroneous reachability attacks. 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. - Most of the attack vectors can be mitigated with careful deployment - and configuration, information learned opportunistically (such as LSB - or gleaning) SHOULD be verified with other reachability mechanisms. - In addition, systematic rate-limitation and filtering is an effective - technique to mitigate attacks that aim to overload the Control-Plane. + 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. + + 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 Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [RFC7052] and [RFC6835]. 18. Changes since RFC 6830 For implementation considerations, the following changes have been @@ -1595,27 +1607,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-02 (work in progress), September 2018. + lisp-6834bis-03 (work in progress), February 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-19 (work in progress), October - 2018. + draft-ietf-lisp-rfc6833bis-24 (work in progress), February + 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 @@ -1631,53 +1643,63 @@ [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, . + [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The + Locator/ID Separation Protocol (LISP) for Multicast + Environments", RFC 6831, DOI 10.17487/RFC6831, January + 2013, . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . + [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID + Separation Protocol (LISP) Multicast", RFC 8378, + DOI 10.17487/RFC8378, May 2018, + . + 20.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private - Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in - progress), May 2018. + 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., @@ -1707,25 +1729,20 @@ [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, . - [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The - Locator/ID Separation Protocol (LISP) for Multicast - Environments", RFC 6831, DOI 10.17487/RFC6831, January - 2013, . - [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, . [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, . @@ -1774,25 +1791,20 @@ [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, "Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, May 2017, . - [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID - Separation Protocol (LISP) Multicast", RFC 8378, - DOI 10.17487/RFC8378, May 2018, - . - Appendix A. Acknowledgments An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a @@ -1835,188 +1847,208 @@ Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed 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-26 +B.1. 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 o Posted late October 2018. o Changed description about "reserved" bits to state "reserved and unassigned". -B.2. Changes to draft-ietf-lisp-rfc6830bis-25 +B.3. 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.3. Changes to draft-ietf-lisp-rfc6830bis-24 +B.4. Changes to draft-ietf-lisp-rfc6830bis-24 o Posted mid October 2018. o Final editorial changes for Eric and Ben. -B.4. Changes to draft-ietf-lisp-rfc6830bis-23 +B.5. 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.5. Changes to draft-ietf-lisp-rfc6830bis-22 +B.6. Changes to draft-ietf-lisp-rfc6830bis-22 o Posted early October 2018. o Changes to reflect comments post Telechat. -B.6. Changes to draft-ietf-lisp-rfc6830bis-21 +B.7. Changes to draft-ietf-lisp-rfc6830bis-21 o Posted late-September 2018. o Changes to reflect comments from Sep 27th Telechat. -B.7. Changes to draft-ietf-lisp-rfc6830bis-20 +B.8. Changes to draft-ietf-lisp-rfc6830bis-20 o Posted late-September 2018. o Fix old reference to RFC3168, changed to RFC6040. -B.8. Changes to draft-ietf-lisp-rfc6830bis-19 +B.9. Changes to draft-ietf-lisp-rfc6830bis-19 o Posted late-September 2018. o More editorial changes. -B.9. Changes to draft-ietf-lisp-rfc6830bis-18 +B.10. Changes to draft-ietf-lisp-rfc6830bis-18 o Posted mid-September 2018. o Changes to reflect comments from Secdir review (Mirja). -B.10. Changes to draft-ietf-lisp-rfc6830bis-17 +B.11. 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.11. Changes to draft-ietf-lisp-rfc6830bis-16 +B.12. 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.12. Changes to draft-ietf-lisp-rfc6830bis-15 +B.13. 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.13. Changes to draft-ietf-lisp-rfc6830bis-14 +B.14. 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.14. Changes to draft-ietf-lisp-rfc6830bis-13 +B.15. 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.15. Changes to draft-ietf-lisp-rfc6830bis-12 +B.16. Changes to draft-ietf-lisp-rfc6830bis-12 o Posted July 2018. o Fixed Luigi editorial comments to ready draft for RFC status. -B.16. Changes to draft-ietf-lisp-rfc6830bis-11 +B.17. 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.17. Changes to draft-ietf-lisp-rfc6830bis-10 +B.18. 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.18. Changes to draft-ietf-lisp-rfc6830bis-09 +B.19. 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.19. Changes to draft-ietf-lisp-rfc6830bis-08 +B.20. 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.20. Changes to draft-ietf-lisp-rfc6830bis-07 +B.21. 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.21. Changes to draft-ietf-lisp-rfc6830bis-06 +B.22. 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". @@ -2025,90 +2057,80 @@ 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.22. Changes to draft-ietf-lisp-rfc6830bis-05 +B.23. 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.23. Changes to draft-ietf-lisp-rfc6830bis-04 +B.24. 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.24. Changes to draft-ietf-lisp-rfc6830bis-03 +B.25. 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.25. Changes to draft-ietf-lisp-rfc6830bis-02 +B.26. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.26. Changes to draft-ietf-lisp-rfc6830bis-01 +B.27. 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.27. Changes to draft-ietf-lisp-rfc6830bis-00 +B.28. 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 - Cisco Systems - Tasman Drive - San Jose, CA 95134 - USA + lispers.net EMail: farinacci@gmail.com Vince Fuller - Cisco Systems - Tasman Drive - San Jose, CA 95134 - USA + vaf.net Internet Consulting EMail: vince.fuller@gmail.com - Dave Meyer - Cisco Systems - 170 Tasman Drive - San Jose, CA - USA + 1-4-5.net EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com