--- 1/draft-ietf-lisp-rfc6830bis-05.txt 2017-10-30 10:13:22.766474736 -0700 +++ 2/draft-ietf-lisp-rfc6830bis-06.txt 2017-10-30 10:13:22.878477393 -0700 @@ -1,22 +1,22 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: March 2, 2018 D. Lewis +Expires: May 3, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - August 29, 2017 + October 30, 2017 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-05 + draft-ietf-lisp-rfc6830bis-06 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. The @@ -28,37 +28,37 @@ among other features. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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 March 2, 2018. + This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 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 - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 @@ -78,21 +78,21 @@ 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 27 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 29 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 30 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 32 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 34 - 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 + 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 35 15. Router Performance Considerations . . . . . . . . . . . . . . 35 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 38 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 @@ -103,26 +103,28 @@ 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 - B.1. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 - B.2. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 - B.3. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 - B.4. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 - B.5. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + B.1. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52 + B.2. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 52 + B.3. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 + B.4. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 + B.5. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 + B.6. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 + B.7. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction 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 @@ -195,31 +197,30 @@ 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. EIDs MUST NOT be used as - LISP RLOCs. 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 global routing system. In theory, the bit string - that represents an EID for one device can represent an RLOC for a - different device. As the architecture is realized, if a given bit - string is both an RLOC and an EID, it must refer to the same - entity in both cases. When used in discussions with other + 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 global routing system. In theory, the bit + string that represents an EID for one device can represent an RLOC + for a different device. As the architecture is realized, if a + given bit string is both an RLOC and an EID, it must refer to the + same entity in both cases. 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. 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 that make up a "database mapping". EID-Prefix allocations can be broken up into smaller blocks when an RLOC set is to be associated with the larger EID-Prefix block. A globally routed address block (whether @@ -239,23 +240,23 @@ supplies an EID value for the destination address field of the IP header when communicating globally (i.e., outside of its routing domain). An end-system can be a host computer, a switch or router device, or any network appliance. 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 globally routable - RLOCs in the source address field and the result of the mapping - lookup in the destination address field. Note that this + 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 @@ -280,77 +281,73 @@ network that strips an outer 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. + Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling + occurs when an RTR (Re-encapsulating Tunnel Router) acts like an + ETR to remove a LISP header, then acts as an ITR to prepend a new + LISP header. Doing this allows a packet to be re-routed by the + RTR without adding the overhead of additional tunnel headers. Any + references to tunnels in this specification refer to dynamic + encapsulating tunnels; they are never statically configured. When + using multiple mapping database systems, care must be taken to not + create re-encapsulation loops through misconfiguration. + LISP Router: A LISP router is a router that performs the functions of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), or Proxy-ETR (PETR). - EID-to-RLOC Map-Cache: The EID-to-RLOC map-cache is a 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. + 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. 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 - globally visible IP addresses. The same database mapping entries - MUST be configured on all ETRs for a given site. In a steady - state, the EID-Prefixes for the site and the Locator-Set for each - EID-Prefix MUST be the same on all ETRs. Procedures to enforce - and/or verify this are outside the scope of this document. 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. + globally visible IP addresses. 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. Recursive Tunneling: Recursive Tunneling occurs when a packet has more than one LISP IP header. Additional layers of tunneling MAY be employed to implement Traffic Engineering or other re-routing as needed. When this is done, an additional "outer" LISP header is added, and the original RLOCs are preserved in the "inner" header. Any references to tunnels in this specification refer to dynamic encapsulating tunnels; they are never statically configured. - Re-encapsulating Tunneling in RTRs: Re-encapsulating Tunneling - occurs when an RTR (Re-encapsulating Tunnel Router) acts like an - ETR to remove a LISP header, then acts as an ITR to prepend a new - LISP header. Doing this allows a packet to be re-routed by the - RTR without adding the overhead of additional tunnel headers. Any - references to tunnels in this specification refer to dynamic - encapsulating tunnels; they are never statically configured. When - using multiple mapping database systems, care must be taken to not - create re-encapsulation loops through misconfiguration. - LISP Header: LISP header is a term used in this document to refer 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. Address Family Identifier (AFI): AFI is a term used to describe an - address encoding in a packet. An address family currently - pertains to an IPv4 or IPv6 address. 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. + address encoding in a packet. An address family that pertains to + the data-plane. 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. 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 or has 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. @@ -391,22 +387,22 @@ in the edge network are the demarcation points to separate the edge network from the core network. Client-side: Client-side is a term used in this document to indicate a connection initiation attempt by an EID. The ITR(s) at the LISP site are the first to get involved in obtaining database Map-Cache entries by sending Map-Request messages. 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. The ETR(s) at the destination LISP site are the - first to send Map-Replies to the source site initiating the + destination EID. The ETR(s) at the destination LISP site may be + the first to send Map-Replies to the source site initiating the connection. The ETR(s) at this destination site can obtain mappings by gleaning information from Map-Requests, Data-Probes, or encapsulated packets. 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. @@ -494,21 +490,21 @@ when re-routing of the path for a packet is desired. A potential use-case for this would be an ISP router that needs to perform Traffic Engineering for packets flowing through its network. In such a situation, termed "Recursive Tunneling", an ISP transit acts as an additional ITR, and the RLOC it uses for the new prepended header would be either a TE-ETR within the ISP (along an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an inter-ISP traffic engineered path, where an agreement to build such a path exists). In order to avoid excessive packet overhead as well as possible - encapsulation loops, this document mandates that a maximum of two + encapsulation loops, this document recommends that a maximum of two LISP headers can be prepended to a packet. For initial LISP deployments, it is assumed that two headers is sufficient, where the first prepended header is used at a site for Location/Identity separation and the second prepended header is used inside a service provider for Traffic Engineering purposes. Tunnel Routers can be placed fairly flexibly in a multi-AS topology. For example, the ITR for a particular end-to-end packet exchange might be the first-hop or default router within a site for the source host. Similarly, the ETR might be the last-hop router directly @@ -1038,21 +1034,22 @@ that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set 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. + 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 [I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the control-plane can store more instances than a given data-plane can 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 Both the client-side and server-side may need control over the @@ -1293,22 +1290,22 @@ reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is 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 Map- - Reply message. + enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- + probe Map-Reply message. Note that other Locator reachability mechanisms are being researched and can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing. 10.2. RLOC-Probing Algorithm RLOC-Probing is a method that an ITR or PITR can use to determine the reachability status of one or more Locators that it has cached in a @@ -1416,23 +1413,23 @@ 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 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, we want - to maintain this approach but need to provide a way for ETRs to - change their mappings and inform the sites that are currently + 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. 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 @@ -1498,21 +1495,22 @@ where mappings change, to control the rate they receive requests for Map-Reply messages. SMRs are also used to tell remote ITRs to update the mappings they have cached. Since the ETRs don't keep track of remote ITRs that have cached their mappings, they do not know which ITRs need to have their mappings updated. As a result, an ETR will solicit Map-Requests (called an SMR message) from those sites to which it has been sending encapsulated data for the last minute. In particular, an ETR will send an SMR to an ITR to which it has recently sent encapsulated - data. + data. This can only occur when both ITR and ETR functionality reside + in the same router. An SMR message is simply a bit set in a Map-Request message. An ITR or PITR will send a Map-Request when they receive an SMR message. Both the SMR sender and the Map-Request responder MUST rate-limit these messages. Rate-limiting can be implemented as a global rate- limiter or one rate-limiter per SMR destination. The following procedure shows how an SMR exchange occurs when a site is doing Locator-Set compaction for an EID-to-RLOC mapping: @@ -1687,22 +1685,22 @@ decoupling the address space used by a site from the address spaces used by its ISPs [RFC4984]. 16.2. Fast Mobility Fast endpoint mobility occurs when an endpoint moves relatively rapidly, changing its IP-layer network attachment point. Maintenance of session continuity is a goal. This is where the Mobile IPv4 [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and primarily where interactions with LISP need to be explored, such as - the mechanisms in [I-D.portoles-lisp-eid-mobility] when the EID moves - but the RLOC is in the network infrastructure. + the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but + the RLOC is in the network infrastructure. In LISP, one possibility is to "glean" information. When a packet arrives, the ETR could examine the EID-to-RLOC mapping and use that mapping for all outgoing traffic to that EID. It can do this after performing a route-returnability check, to ensure that the new network location does have an internal route to that endpoint. However, this does not cover the case where an ITR (the node assigned the RLOC) at the mobile-node location has been compromised. Mobile IP packet exchange is designed for an environment in which all @@ -1724,23 +1722,22 @@ for any endpoint will return a binding for the entire mobile prefix. If mobile networks become a more common occurrence, it may be useful to revisit the design of the mapping service and allow for dynamic updates of the database. The issue of interactions between mobility and LISP needs to be explored further. Specific improvements to the entire system will depend on the details of mapping mechanisms. Mapping mechanisms should be evaluated on how well they support session continuity for - mobile nodes. See [I-D.farinacci-lisp-predictive-rlocs] for more - recent mechanisms which can provide near-zero packet loss during - handoffs. + mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent + mechanisms which can provide near-zero packet loss during handoffs. 16.3. LISP Mobile Node Mobility A mobile device can use the LISP infrastructure to achieve mobility by implementing the LISP encapsulation and decapsulation functions and acting as a simple ITR/ETR. By doing this, such a "LISP mobile node" can use topologically independent EID IP addresses that are not advertised into and do not impose a cost on the global routing system. These EIDs are maintained at the edges of the mapping system in LISP Map-Servers and Map-Resolvers) and are provided on demand to @@ -1880,27 +1877,29 @@ and provider want control, then Recursive or Re-Encapsulating Tunnels are used. 17.4. LISP Functionality with Conventional NATs LISP routers can be deployed behind Network Address Translator (NAT) devices to provide the same set of packet services hosts have today when they are addressed out of private address space. It is important to note that a locator address in any LISP control - message MUST be a globally routable address and therefore SHOULD NOT - contain [RFC1918] addresses. If a LISP xTR is configured with - private RLOC addresses, they MUST be used only in the outer IP header - so the NAT device can translate properly. Otherwise, EID addresses - MUST be translated before encapsulation is performed when LISP VPNs - are not in use. Both NAT translation and LISP encapsulation - functions could be co-located in the same device. + message MUST be a routable address and therefore [RFC1918] addresses + SHOULD only be presence when running in a local environment. When a + LISP xTR is configured with private RLOC addresses and resides behind + a NAT device and desires to communicate on the Internet, the private + addresses MUST be used only in the outer IP header so the NAT device + can translate properly. Otherwise, EID addresses MUST be translated + before encapsulation is performed when LISP VPNs are not in use. + Both NAT translation and LISP encapsulation functions could be co- + located in the same device. 17.5. Packets Egressing a LISP Site When a LISP site is using two ITRs for redundancy, the failure of one ITR will likely shift outbound traffic to the second. This second ITR's cache may not be populated with the same EID-to-RLOC mapping entries as the first. If this second ITR does not have these mappings, traffic will be dropped while the mappings are retrieved from the mapping system. The retrieval of these messages may increase the load of requests being sent into the mapping system. @@ -2083,259 +2082,264 @@ [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-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", - draft-ietf-lisp-rfc6833bis-05 (work in progress), May + draft-ietf-lisp-rfc6833bis-06 (work in progress), October 2017. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. - Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12 - (work in progress), November 2016. + Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 + (work in progress), October 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - DOI 10.17487/RFC0768, August 1980, . + DOI 10.17487/RFC0768, August 1980, + . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, - DOI 10.17487/RFC0791, September 1981, . + DOI 10.17487/RFC0791, September 1981, + . [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + DOI 10.17487/RFC2119, March 1997, + . [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, . [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, - DOI 10.17487/RFC4086, June 2005, . + DOI 10.17487/RFC4086, June 2005, + . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, - DOI 10.17487/RFC4868, May 2007, . + DOI 10.17487/RFC4868, May 2007, + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, - DOI 10.17487/RFC5226, May 2008, . + DOI 10.17487/RFC5226, May 2008, + . [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, - DOI 10.17487/RFC5496, March 2009, . + DOI 10.17487/RFC5496, March 2009, + . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, . [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", RFC 6115, DOI 10.17487/RFC6115, February 2011, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, - DOI 10.17487/RFC6834, January 2013, . + DOI 10.17487/RFC6834, January 2013, + . [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, . [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID Separation Protocol (LISP) MIB", RFC 7052, - DOI 10.17487/RFC7052, October 2013, . + DOI 10.17487/RFC7052, October 2013, + . [RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry", RFC 7214, DOI 10.17487/RFC7214, May 2014, . [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, . [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, - DOI 10.17487/RFC7833, May 2016, . + DOI 10.17487/RFC7833, May 2016, + . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, - DOI 10.17487/RFC7835, April 2016, . + DOI 10.17487/RFC7835, April 2016, + . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, - DOI 10.17487/RFC8061, February 2017, . + DOI 10.17487/RFC8061, February 2017, + . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, - DOI 10.17487/RFC8200, July 2017, . + DOI 10.17487/RFC8200, July 2017, + . 22.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . - [I-D.farinacci-lisp-predictive-rlocs] - Farinacci, D. and P. Pillay-Esnault, "LISP Predictive - RLOCs", draft-farinacci-lisp-predictive-rlocs-02 (work in - progress), May 2017. + [I-D.ietf-lisp-eid-mobility] + Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, + F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a + Unified Control Plane", draft-ietf-lisp-eid-mobility-00 + (work in progress), May 2017. [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP - Mobile Node", draft-ietf-lisp-mn-00 (work in progress), - April 2017. + Mobile Node", draft-ietf-lisp-mn-01 (work in progress), + October 2017. + + [I-D.ietf-lisp-predictive-rlocs] + Farinacci, D. and P. Pillay-Esnault, "LISP Predictive + RLOCs", draft-ietf-lisp-predictive-rlocs-00 (work in + progress), June 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", draft-ietf-lisp-signal-free-multicast-06 (work in progress), August 2017. + [I-D.ietf-lisp-vpn] + Moreno, V. and D. Farinacci, "LISP Virtual Private + Networks (VPNs)", draft-ietf-lisp-vpn-00 (work in + progress), May 2017. + [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01 (work in progress), January 2009. - [I-D.portoles-lisp-eid-mobility] - Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, - F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a - Unified Control Plane", draft-portoles-lisp-eid- - mobility-02 (work in progress), April 2017. - [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, "Renumbering: Threat or Menace?", Usenix Tenth System Administration Conference (LISA 96), October 1996. [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, . [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, - DOI 10.17487/RFC2784, March 2000, . + DOI 10.17487/RFC2784, March 2000, + . [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, - DOI 10.17487/RFC3261, June 2002, . + DOI 10.17487/RFC3261, June 2002, + . [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, . [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, - DOI 10.17487/RFC4192, September 2005, . + DOI 10.17487/RFC4192, September 2005, + . [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, - DOI 10.17487/RFC4866, May 2007, . + DOI 10.17487/RFC4866, May 2007, + . [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, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, - DOI 10.17487/RFC6518, February 2012, . + DOI 10.17487/RFC6518, February 2012, + . [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, . + 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, . + DOI 10.17487/RFC6835, January 2013, + . [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, - DOI 10.17487/RFC6837, January 2013, . + DOI 10.17487/RFC6837, January 2013, + . [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, - DOI 10.17487/RFC6935, April 2013, . + DOI 10.17487/RFC6935, April 2013, + . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . @@ -2377,62 +2381,92 @@ The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] -B.1. Changes to draft-ietf-lisp-rfc6830bis-04 +B.1. Changes to draft-ietf-lisp-rfc6830bis-06 + + o Posted October 2017. + + o Put RTR definition before it is used. + + o Rename references that are now working group drafts. + + o Remove "EIDs MUST NOT be used as used by a host to refer to other + hosts. Note that EID blocks MAY LISP RLOCs". + + o Indicate what address-family can appear in data packets. + + o ETRs may, rather than will, be the ones to send Map-Replies. + + o Recommend, rather than mandate, max encapsulation headers to 2. + + o Reference VPN draft when introducing Instance-ID. + + o Indicate that SMRs can be sent when ITR/ETR are in the same node. + + o Clarify when private addreses can be used. + +B.2. Changes to draft-ietf-lisp-rfc6830bis-05 + + o Posted August 2017. + + o Make it clear that a Reencapsulating Tunnel Router is an RTR. + +B.3. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. -B.2. Changes to draft-ietf-lisp-rfc6830bis-03 +B.4. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. -B.3. Changes to draft-ietf-lisp-rfc6830bis-02 +B.5. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.4. Changes to draft-ietf-lisp-rfc6830bis-01 +B.6. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o 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.5. Changes to draft-ietf-lisp-rfc6830bis-00 +B.7. 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 EMail: farinacci@gmail.com Vince Fuller Cisco Systems