--- 1/draft-ietf-lisp-rfc6830bis-10.txt 2018-03-05 14:13:15.515432381 -0800 +++ 2/draft-ietf-lisp-rfc6830bis-11.txt 2018-03-05 14:13:15.607434580 -0800 @@ -1,22 +1,22 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: September 5, 2018 D. Lewis +Expires: September 6, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - March 4, 2018 + March 5, 2018 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-10 + draft-ietf-lisp-rfc6830bis-11 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. @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 5, 2018. + This Internet-Draft will expire on September 6, 2018. Copyright Notice Copyright (c) 2018 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 @@ -58,73 +58,61 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 10 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 12 - 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 - 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 - 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 + 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 12 + 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 13 + 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 14 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 - 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 + 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 - 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 + 8. Using Virtualization and Segmentation with LISP . . . . . . . 21 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 - 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 + 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 26 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 29 - 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 30 + 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 15. Router Performance Considerations . . . . . . . . . . . . . . 31 - 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 32 - 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 32 - 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 32 - 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 33 - 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 33 - 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 35 - 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 35 - 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 36 - 17.4. LISP Functionality with Conventional NATs . . . . . . . 36 - 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 37 - 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 37 - 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 38 - 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 38 - 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 39 - 19. Security Considerations . . . . . . . . . . . . . . . . . . . 39 - 20. Network Management Considerations . . . . . . . . . . . . . . 40 - 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 - 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 40 - 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 22.1. Normative References . . . . . . . . . . . . . . . . . . 40 - 22.2. Informative References . . . . . . . . . . . . . . . . . 41 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46 - Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46 - B.1. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 47 - B.2. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 47 - B.3. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 47 - B.4. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 48 - B.5. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 48 - B.6. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 48 - B.7. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 48 - B.8. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 49 - B.9. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 49 - B.10. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 49 - B.11. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 49 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 + 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 17. Network Management Considerations . . . . . . . . . . . . . . 32 + 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 18.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 33 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 19.2. Informative References . . . . . . . . . . . . . . . . . 34 + + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 + Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 + B.1. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 40 + B.2. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 40 + B.3. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 40 + B.4. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 40 + B.5. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 41 + B.6. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 41 + B.7. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 41 + B.8. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 41 + B.9. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 42 + B.10. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 42 + B.11. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 42 + B.12. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 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 @@ -849,22 +834,21 @@ 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. See Section 18.3 for TTL exception handling for - traceroute packets. + 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 [RFC3168]. The 'ECN' field requires special treatment in order to avoid discarding indications of congestion [RFC3168]. 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/ @@ -1088,21 +1072,21 @@ 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 19 for security + "gleaning" mechanism is OPTIONAL, 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 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. @@ -1157,21 +1141,21 @@ 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 19 for security related + particular EID-Prefix. Refer to Section 16 for security related issues regarding Locator-Status-Bits. When an ETR decapsulates a packet, it knows that it is reachable from the encapsulating ITR because that is how the packet arrived. 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. @@ -1467,365 +1451,23 @@ octets to a MAC rewrite string and prepending the string as part of the outgoing encapsulation procedure. Routers that support Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already support this action. 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 19. - -16. Mobility Considerations - - There are several kinds of mobility, of which only some might be of - concern to LISP. Essentially, they are as follows. - -16.1. Slow Mobility - - A site wishes to change its attachment points to the Internet, and - its LISP Tunnel Routers will have new RLOCs when it changes upstream - providers. Changes in EID-to-RLOC mappings for sites are expected to - be handled by configuration, outside of LISP. - - An individual endpoint wishes to move but is not concerned about - maintaining session continuity. Renumbering is involved. LISP can - help with the issues surrounding renumbering [RFC4192] [LISA96] by - 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.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 - routing information is disseminated before packets can be forwarded. - In order to allow the Internet to grow to support expected future - use, we are moving to an environment where some information may have - to be obtained after packets are in flight. Modifications to IP - mobility should be considered in order to optimize the behavior of - the overall system. Anything that decreases the number of new EID- - to-RLOC mappings needed when a node moves, or maintains the validity - of an EID-to-RLOC mapping for a longer time, is useful. - - In addition to endpoints, a network can be mobile, possibly changing - xTRs. A "network" can be as small as a single router and as large as - a whole site. This is different from site mobility in that it is - fast and possibly short-lived, but different from endpoint mobility - in that a whole prefix is changing RLOCs. However, the mechanisms - are the same, and there is no new overhead in LISP. A map request - 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.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 - only the correspondents of the LISP mobile node. - - Refer to [I-D.ietf-lisp-mn] for more details for when the EID and - RLOC are co-located in the roaming node. - -17. LISP xTR Placement and Encapsulation Methods - - This section will explore how and where ITRs and ETRs can be placed - in the network and will discuss the pros and cons of each scenario. - For a more detailed network design deployment recommendation, refer - to [RFC7215]. - - There are two basic deployment tradeoffs to consider: centralized - versus distributed caches; and flat, Recursive, or Re-encapsulating - Tunneling. When deciding on centralized versus distributed caching, - the following issues SHOULD be considered: - - o Are the xTRs spread out so that the caches are spread across all - the memories of each router? A centralized cache is when an ITR - keeps a cache for all the EIDs it is encapsulating to. The packet - takes a direct path to the destination Locator. A distributed - cache is when an ITR needs help from other Re-Encapsulating Tunnel - Routers (RTRs) because it does not store all the cache entries for - the EIDs it is encapsulating to. So, the packet takes a path - through RTRs that have a different set of cache entries. - - o Should management "touch points" be minimized by only choosing a - few xTRs, just enough for redundancy? - - o In general, using more ITRs doesn't increase management load, - since caches are built and stored dynamically. On the other hand, - using more ETRs does require more management, since EID-Prefix-to- - RLOC mappings need to be explicitly configured. - - When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the - following issues SHOULD be considered: - - o Flat tunneling implements a single encapsulation path between the - source site and destination site. This generally offers better - paths between sources and destinations with a single encapsulation - path. - - o Recursive Tunneling is when encapsulated traffic is again further - encapsulated in another tunnel, either to implement VPNs or to - perform Traffic Engineering. When doing VPN-based tunneling, the - site has some control, since the site is prepending a new - encapsulation header. In the case of TE-based tunneling, the site - MAY have control if it is prepending a new tunnel header, but if - the site's ISP is doing the TE, then the site has no control. - Recursive Tunneling generally will result in suboptimal paths but - with the benefit of steering traffic to parts of the network that - have more resources available. - - o The technique of Re-Encapsulation ensures that packets only - require one encapsulation header. So, if a packet needs to be re- - routed, it is first decapsulated by the RTR and then Re- - Encapsulated with a new encapsulation header using a new RLOC. - - The next sub-sections will examine where xTRs and RTRs can reside in - the network. - -17.1. First-Hop/Last-Hop xTRs - - By locating xTRs close to hosts, the EID-Prefix set is at the - granularity of an IP subnet. So, at the expense of more EID-Prefix- - to-RLOC sets for the site, the caches in each xTR can remain - relatively small. But caches always depend on the number of non- - aggregated EID destination flows active through these xTRs. - - With more xTRs doing encapsulation, the increase in control traffic - grows as well: since the EID granularity is greater, more Map- - Requests and Map-Replies are traveling between more routers. - - The advantage of placing the caches and databases at these stub - routers is that the products deployed in this part of the network - have better price-memory ratios than their core router counterparts. - Memory is typically less expensive in these devices, and fewer routes - are stored (only IGP routes). These devices tend to have excess - capacity, both for forwarding and routing states. - - LISP functionality can also be deployed in edge switches. These - devices generally have layer-2 ports facing hosts and layer-3 ports - facing the Internet. Spare capacity is also often available in these - devices. - -17.2. Border/Edge xTRs - - Using Customer Edge (CE) routers for xTR placement allows the EID - space associated with a site to be reachable via a small set of RLOCs - assigned to the CE-based xTRs for that site. - - This offers the opposite benefit of the first-hop/last-hop xTR - scenario: the number of mapping entries and network management touch - points is reduced, allowing better scaling. - - One disadvantage is that fewer network resources are used to reach - host endpoints, thereby centralizing the point-of-failure domain and - creating network choke points at the CE xTR. - - Note that more than one CE xTR at a site can be configured with the - same IP address. In this case, an RLOC is an anycast address. This - allows resilience between the CE xTRs. That is, if a CE xTR fails, - traffic is automatically routed to the other xTRs using the same - anycast address. However, this comes with the disadvantage where the - site cannot control the entrance point when the anycast route is - advertised out from all border routers. Another disadvantage of - using anycast Locators is the limited advertisement scope of /32 (or - /128 for IPv6) routes. - -17.3. ISP Provider Edge (PE) xTRs - - The use of ISP PE routers as xTRs is not the typical deployment - scenario envisioned in this specification. This section attempts to - capture some of the reasoning behind this preference for implementing - LISP on CE routers. - - The use of ISP PE routers for xTR placement gives an ISP, rather than - a site, control over the location of the ETRs. That is, the ISP can - decide whether the xTRs are in the destination site (in either CE - xTRs or last-hop xTRs within a site) or at other PE edges. The - advantage of this case is that two encapsulation headers can be - avoided. By having the PE be the first router on the path to - encapsulate, it can choose a TE path first, and the ETR can - decapsulate and Re-Encapsulate for a new encapsulation path to the - destination end site. - - An obvious disadvantage is that the end site has no control over - where its packets flow or over the RLOCs used. Other disadvantages - include difficulty in synchronizing path liveness updates between CE - and PE routers. - - As mentioned in earlier sections, a combination of these scenarios is - possible at the expense of extra packet header overhead; if both site - 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 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. - -18. Traceroute Considerations - - When a source host in a LISP site initiates a traceroute to a - destination host in another LISP site, it is highly desirable for it - to see the entire path. Since packets are encapsulated from the ITR - to the ETR, the hop across the tunnel could be viewed as a single - hop. However, LISP traceroute will provide the entire path so the - user can see 3 distinct segments of the path from a source LISP host - to a destination LISP host: - - Segment 1 (in source LISP site based on EIDs): - - source host ---> first hop ... next hop ---> ITR - - Segment 2 (in the core network based on RLOCs): - - ITR ---> next hop ... next hop ---> ETR - - Segment 3 (in the destination LISP site based on EIDs): - - ETR ---> next hop ... last hop ---> destination host - - For segment 1 of the path, ICMP Time Exceeded messages are returned - in the normal manner as they are today. The ITR performs a TTL - decrement and tests for 0 before encapsulating. Therefore, the ITR's - hop is seen by the traceroute source as having an EID address (the - address of the site-facing interface). - - For segment 2 of the path, ICMP Time Exceeded messages are returned - to the ITR because the TTL decrement to 0 is done on the outer - header, so the destinations of the ICMP messages are the ITR RLOC - address and the source RLOC address of the encapsulated traceroute - packet. The ITR looks inside of the ICMP payload to inspect the - traceroute source so it can return the ICMP message to the address of - the traceroute client and also retain the core router IP address in - the ICMP message. This is so the traceroute client can display the - core router address (the RLOC address) in the traceroute output. The - ETR returns its RLOC address and responds to the TTL decrement to 0, - as the previous core routers did. - - For segment 3, the next-hop router downstream from the ETR will be - decrementing the TTL for the packet that was encapsulated, sent into - the core, decapsulated by the ETR, and forwarded because it isn't the - final destination. If the TTL is decremented to 0, any router on the - path to the destination of the traceroute, including the next-hop - router or destination, will send an ICMP Time Exceeded message to the - source EID of the traceroute client. The ICMP message will be - encapsulated by the local ITR and sent back to the ETR in the - originated traceroute source site, where the packet will be delivered - to the host. - -18.1. IPv6 Traceroute - - IPv6 traceroute follows the procedure described above, since the - entire traceroute data packet is included in the ICMP Time Exceeded - message payload. Therefore, only the ITR needs to pay special - attention to forwarding ICMP messages back to the traceroute source. - -18.2. IPv4 Traceroute - - For IPv4 traceroute, we cannot follow the above procedure, since IPv4 - ICMP Time Exceeded messages only include the invoking IP header and - 8 octets that follow the IP header. Therefore, when a core router - sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the - ICMP payload is the encapsulated header it prepended, followed by a - UDP header. The original invoking IP header, and therefore the - identity of the traceroute source, is lost. - - The solution we propose to solve this problem is to cache traceroute - IPv4 headers in the ITR and to match them up with corresponding IPv4 - Time Exceeded messages received from core routers and the ETR. The - ITR will use a circular buffer for caching the IPv4 and UDP headers - of traceroute packets. It will select a 16-bit number as a key to - find them later when the IPv4 Time Exceeded messages are received. - When an ITR encapsulates an IPv4 traceroute packet, it will use the - 16-bit number as the UDP source port in the encapsulating header. - When the ICMP Time Exceeded message is returned to the ITR, the UDP - header of the encapsulating header is present in the ICMP payload, - thereby allowing the ITR to find the cached headers for the - traceroute source. The ITR puts the cached headers in the payload - and sends the ICMP Time Exceeded message to the traceroute source - retaining the source address of the original ICMP Time Exceeded - message (a core router or the ETR of the site of the traceroute - destination). - - The signature of a traceroute packet comes in two forms. The first - form is encoded as a UDP message where the destination port is - inspected for a range of values. The second form is encoded as an - ICMP message where the IP identification field is inspected for a - well-known value. - -18.3. Traceroute Using Mixed Locators - - When either an IPv4 traceroute or IPv6 traceroute is originated and - the ITR encapsulates it in the other address family header, one - cannot get all 3 segments of the traceroute. Segment 2 of the - traceroute cannot be conveyed to the traceroute source, since it is - expecting addresses from intermediate hops in the same address format - for the type of traceroute it originated. Therefore, in this case, - segment 2 will make the tunnel look like one hop. All the ITR has to - do to make this work is to not copy the inner TTL to the outer, - encapsulating header's TTL when a traceroute packet is encapsulated - using an RLOC from a different address family. This will cause no - TTL decrement to 0 to occur in core routers between the ITR and ETR. + Section 16. -19. Security Considerations +16. Security Considerations Security considerations for LISP are discussed in [RFC7833]. A complete LISP threat analysis can be found in [RFC7835], in what follows we provide a summary. 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 @@ -1850,43 +1492,43 @@ 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. -20. Network Management Considerations +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]. -21. IANA Considerations +18. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this data-plane LISP specification, in accordance with BCP 26 [RFC8126]. -21.1. LISP UDP Port Numbers +18.1. LISP UDP Port Numbers The IANA registry has allocated UDP port number 4341 for the LISP data-plane. IANA has updated the description for UDP port 4341 as follows: lisp-data 4341 udp LISP Data Packets -22. References +19. References -22.1. Normative References +19.1. Normative References [I-D.ietf-lisp-rfc6833bis] Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, "Locator/ID Separation Protocol (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-07 (work in progress), December 2017. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . @@ -1913,21 +1555,21 @@ [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . -22.2. Informative References +19.2. Informative References [AFN] IANA, "Address Family Numbers", August 2016, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . [I-D.ietf-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, @@ -2142,72 +1784,80 @@ 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-10 +B.1. 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.2. 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.2. Changes to draft-ietf-lisp-rfc6830bis-09 +B.3. 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.3. Changes to draft-ietf-lisp-rfc6830bis-08 +B.4. 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.4. Changes to draft-ietf-lisp-rfc6830bis-07 +B.5. 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.5. Changes to draft-ietf-lisp-rfc6830bis-06 +B.6. 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". @@ -2216,61 +1866,61 @@ o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addreses can be used. -B.6. Changes to draft-ietf-lisp-rfc6830bis-05 +B.7. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. -B.7. Changes to draft-ietf-lisp-rfc6830bis-04 +B.8. 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.8. Changes to draft-ietf-lisp-rfc6830bis-03 +B.9. 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.9. Changes to draft-ietf-lisp-rfc6830bis-02 +B.10. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.10. Changes to draft-ietf-lisp-rfc6830bis-01 +B.11. 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.11. Changes to draft-ietf-lisp-rfc6830bis-00 +B.12. 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