--- 1/draft-ietf-lisp-rfc6830bis-09.txt 2018-03-04 16:13:36.958780205 -0800 +++ 2/draft-ietf-lisp-rfc6830bis-10.txt 2018-03-04 16:13:37.070782875 -0800 @@ -1,22 +1,22 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: August 17, 2018 D. Lewis +Expires: September 5, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - February 13, 2018 + March 4, 2018 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-09 + draft-ietf-lisp-rfc6830bis-10 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 August 17, 2018. + This Internet-Draft will expire on September 5, 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 @@ -68,64 +68,63 @@ 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7.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 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 - 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 - 10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 - 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 28 - 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 - 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 - 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 - 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 31 - 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 - 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 - 15. Router Performance Considerations . . . . . . . . . . . . . . 34 - 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35 - 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 35 - 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 35 - 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 36 - 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 - 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 - 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 38 - 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 - 17.4. LISP Functionality with Conventional NATs . . . . . . . 39 - 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 - 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40 - 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41 - 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 41 - 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 - 19. Security Considerations . . . . . . . . . . . . . . . . . . . 42 - 20. Network Management Considerations . . . . . . . . . . . . . . 43 - 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 - 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 43 - 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 - 22.1. Normative References . . . . . . . . . . . . . . . . . . 43 - 22.2. Informative References . . . . . . . . . . . . . . . . . 45 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 49 - Appendix B. Document Change Log . . . . . . . . . . . . . . . . 49 - B.1. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 50 - B.2. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 50 - B.3. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 50 - B.4. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 50 - B.5. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51 - B.6. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 51 - B.7. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 51 - B.8. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 51 - B.9. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 51 - B.10. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 + 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 + 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 + 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 + 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 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 @@ -731,21 +730,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored and has no meaning when the N-bit is set to 0. When the N-bit is set to 1 and this bit is set to 1, an ITR is requesting that the nonce value in the 'Nonce' field be echoed back in LISP- encapsulated packets when the ITR is also an ETR. See Section 10.1 for details. V: The V-bit is the Map-Version present bit. When this bit is set to - 1, the N-bit MUST be 0. Refer to Section 13.3 for more details. + 1, the N-bit MUST be 0. Refer to Section 13.2 for more details. This bit indicates that the LISP header is encoded in this case as: 0 x 0 1 x x x x +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -1020,26 +1019,35 @@ 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 - Both the client-side and server-side MAY need control over the - selection of RLOCs for conversations between them. This control is - achieved by manipulating the 'Priority' and 'Weight' fields in EID- - to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be - gleaned from received tunneled packets or EID-to-RLOC Map-Request - messages. + 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. + + The RLOC with the lowest 'Priority' is selected. An RLOC with + 'Priority' 255 means that MUST NOT be used for forwarding. When + multiple RLOC have the same 'Priority' then the 'Weight' states how + to load balance traffic among them. The value of the 'Weight' + represents the relative weight of the total packets that match the + maping entry. The following are different scenarios for choosing RLOCs and the controls that are available: o The server-side returns one RLOC. The client-side can only use one RLOC. The server-side has complete control of the selection. o The server-side returns a list of RLOCs where a subset of the list has the same best Priority. The client can only use the subset list according to the weighting assigned by the server-side. In @@ -1068,161 +1076,104 @@ outer-header source RLOC of received packets. The client-side ITR controls how traffic is returned and can alternate using an outer- header source RLOC, which then can be added to the list the server-side ETR uses to return traffic. Since no Priority or Weights are provided using this method, the server-side ETR MUST assume that each client-side ITR RLOC uses the same best Priority with a Weight of zero. In addition, since EID-Prefix encoding cannot be conveyed in data packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be very large. - o 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. + Alternatively, RLOC information MAY be gleaned from received tunneled + packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache + entry, one learned from the source RLOC of a received encapsulated + packet, is only stored and used for a few seconds, pending + verification. Verification is performed by sending a Map-Request to + the source EID (the inner-header IP source address) of the received + encapsulated packet. A reply to this "verifying Map-Request" is used + to fully populate the Map-Cache entry for the "gleaned" EID and is + stored and used for the time indicated from the 'TTL' field of a + received Map-Reply. When a verified Map-Cache entry is stored, data + gleaning no longer occurs for subsequent packets that have a source + EID that matches the EID-Prefix of the verified entry. This + "gleaning" mechanism is OPTIONAL, refer to Section 19 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. 10. Routing Locator Reachability - Several mechanisms for determining RLOC reachability are currently - defined: + Several data-plane mechanisms for determining RLOC reachability are + currently defined. Please note that additional control-plane based + reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of an encapsulated data packet received from an ITR. If the ETR is also acting as an ITR and has traffic to return to the original ITR site, it can use this status information to help select an RLOC. - 2. An ITR MAY receive an ICMP Network Unreachable or Host - Unreachable message for an RLOC it is using. This indicates that - the RLOC is likely down. Note that trusting ICMP messages may - not be desirable, but neither is ignoring them completely. - Implementations are encouraged to follow current best practices - in treating these conditions [I-D.ietf-opsec-icmp-filtering]. - - 3. When an ITR participates in the routing protocol that operates in - the underlay routing system, it can determine that an RLOC is - down when no Routing Information Base (RIB) entry exists that - matches the RLOC IP address. - - 4. An ITR MAY receive an ICMP Port Unreachable message from a - destination host. This occurs if an ITR attempts to use - interworking [RFC6832] and LISP-encapsulated data is sent to a - non-LISP-capable site. - - 5. An ITR MAY receive a Map-Reply from an ETR in response to a - previously sent Map-Request. The RLOC source of the Map-Reply is - likely up, since the ETR was able to send the Map-Reply to the - ITR. - - 6. When an ETR receives an encapsulated packet from an ITR, the + 2. When an ETR receives an encapsulated packet from an ITR, the source RLOC from the outer header of the packet is likely up. - 7. An ITR/ETR pair can use the Locator reachability algorithms - described in this section, namely Echo-Noncing or RLOC-Probing. + 3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability + algorithms described in this section. When determining Locator up/down reachability by examining the Locator-Status-Bits from the LISP-encapsulated data packet, an ETR will receive up-to-date status from an encapsulating ITR about reachability for all ETRs at the site. CE-based ITRs at the source site can determine reachability relative to each other using the site IGP as follows: o Under normal circumstances, each ITR will advertise a default route into the site IGP. o If an ITR fails or if the upstream link to its PE fails, its default route will either time out or be withdrawn. Each ITR can thus observe the presence or lack of a default route originated by the others to determine the Locator-Status-Bits it sets for them. + When ITRs at the site are not deployed in CE routers, the IGP can + still be used to determine the reachability of Locators, provided + they are injected into the IGP. This is typically done when a /32 + address is configured on a loopback interface. + RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 to n-1 starting with the least significant bit. For example, if an RLOC listed in the 3rd position of the Map-Reply goes down (ordinal value 2), then all ITRs at the site will clear the 3rd least significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for the packets they encapsulate. When an ETR decapsulates a packet, it will check for any change in the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the ETR, if acting also as an ITR, will refrain from encapsulating packets to an RLOC that is indicated as down. It will only resume using that RLOC if the corresponding Locator-Status-Bit returns to a value of 1. Locator-Status-Bits are associated with a Locator-Set per EID-Prefix. Therefore, when a Locator becomes unreachable, the Locator-Status-Bit that corresponds to that Locator's position in the list returned by the last Map-Reply will be set to zero for that particular EID-Prefix. Refer to Section 19 for security related issues regarding Locator-Status-Bits. - When ITRs at the site are not deployed in CE routers, the IGP can - still be used to determine the reachability of Locators, provided - they are injected into the IGP. This is typically done when a /32 - address is configured on a loopback interface. - - When ITRs receive ICMP Network Unreachable or Host Unreachable - messages as a method to determine unreachability, they will refrain - from using Locators that are described in Locator lists of Map- - Replies. However, using this approach is unreliable because many - network operators turn off generation of ICMP Destination Unreachable - messages. - - If an ITR does receive an ICMP Network Unreachable or Host - Unreachable message, it MAY originate its own ICMP Destination - Unreachable message destined for the host that originated the data - packet the ITR encapsulated. - - Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a - locator address from a Locator-Set in a mapping entry matches a - prefix. If it does not find one and BGP is running in the Default- - Free Zone (DFZ), it can decide to not use the Locator even though the - Locator-Status-Bits indicate that the Locator is up. In this case, - the path from the ITR to the ETR that is assigned the Locator is not - available. More details are in [I-D.meyer-loc-id-implications]. - - Optionally, an ITR can send a Map-Request to a Locator, and if a Map- - Reply is returned, reachability of the Locator has been determined. - Obviously, sending such probes increases the number of control - messages originated by Tunnel Routers for active flows, so Locators - are assumed to be reachable when they are advertised. - - This assumption does create a dependency: Locator unreachability is - detected by the receipt of ICMP Host Unreachable messages. When a - Locator has been determined to be unreachable, it is not used for - active traffic; this is the same as if it were listed in a Map-Reply - with Priority 255. - - The ITR can test the reachability of the unreachable Locator by - sending periodic Requests. Both Requests and Replies MUST be rate- - limited. Locator reachability testing is never done with data - packets, since that increases the risk of packet loss for end-to-end - sessions. - 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. 10.1. Echo Nonce Algorithm @@ -1270,64 +1221,20 @@ 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. - Note other Locator Reachability mechanisms 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 - Map-Cache entry. The probe-bit of the Map-Request and Map-Reply - messages is used for RLOC-Probing. - - RLOC-Probing is done in the control plane on a timer basis, where an - ITR or PITR will originate a Map-Request destined to a locator - address from one of its own locator addresses. A Map-Request used as - an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to - the mapping database system as one would when soliciting mapping - data. The EID record encoded in the Map-Request is the EID-Prefix of - the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a - mapping data record for its own database mapping information that - contains the local EID-Prefixes and RLOCs for its site. RLOC-probes - are sent periodically using a jittered timer interval. - - When an ETR receives a Map-Request message with the probe-bit set, it - returns a Map-Reply with the probe-bit set. The source address of - the Map-Reply is set according to the procedure described in - [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping - data for the EID-Prefix contained in the Map-Request. This provides - the opportunity for the ITR or PITR that sent the RLOC-probe to get - mapping updates if there were changes to the ETR's database mapping - entries. - - There are advantages and disadvantages of RLOC-Probing. The greatest - benefit of RLOC-Probing is that it can handle many failure scenarios - allowing the ITR to determine when the path to a specific Locator is - reachable or has become unreachable, thus providing a robust - mechanism for switching to using another Locator from the cached - Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) - estimates between a pair of Locators, which can be useful for network - management purposes as well as for selecting low delay paths. The - major disadvantage of RLOC-Probing is in the number of control - messages required and the amount of bandwidth used to obtain those - benefits, especially if the requirement for failure detection times - is very small. - 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 @@ -1390,55 +1297,61 @@ Since the LISP architecture uses a caching scheme to retrieve and store EID-to-RLOC mappings, the only way an ITR can get a more up-to- date mapping is to re-request the mapping. However, the ITRs do not know when the mappings change, and the ETRs do not keep track of which ITRs requested its mappings. For scalability reasons, it is desirable to maintain this approach but need to provide a way for ETRs to change their mappings and inform the sites that are currently communicating with the ETR site using such mappings. + This section defines data-plane mechanisms for updating EID-to-RLOC + mappings. Additionally, the Solicit-Map Request (SMR) control-plane + updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis]. + When adding a new Locator record in lexicographic order to the end of a Locator-Set, it is easy to update mappings. We assume that new mappings will maintain the same Locator ordering as the old mapping but will just have new Locators appended to the end of the list. So, some ITRs can have a new mapping while other ITRs have only an old mapping that is used until they time out. When an ITR has only an old mapping but detects bits set in the Locator-Status-Bits that correspond to Locators beyond the list it has cached, it simply ignores them. However, this can only happen for locator addresses that are lexicographically greater than the locator addresses in the existing Locator-Set. When a Locator record is inserted in the middle of a Locator-Set, to - maintain lexicographic order, the SMR procedure in Section 13.2 is - used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. + maintain lexicographic order, SMR procedure + [I-D.ietf-lisp-rfc6833bis] is used to inform ITRs and PITRs of the + new Locator-Status-Bit mappings. When a Locator record is removed from a Locator-Set, ITRs that have the mapping cached will not use the removed Locator because the xTRs will set the Locator-Status-Bit to 0. So, even if the Locator is in the list, it will not be used. For new mapping requests, the xTRs can set the Locator AFI to 0 (indicating an unspecified address), as well as setting the corresponding Locator-Status-Bit to 0. This forces ITRs with old or new mappings to avoid using the removed Locator. If many changes occur to a mapping over a long period of time, one will find empty record slots in the middle of the Locator-Set and new records appended to the Locator-Set. At some point, it would be useful to compact the Locator-Set so the Locator-Status-Bit settings can be efficiently packed. - We propose here three approaches for Locator-Set compaction: one - operational mechanism and two protocol mechanisms. The operational - approach uses a clock sweep method. The protocol approaches use the - concept of Solicit-Map-Requests and Map-Versioning. + We propose here two approaches for Locator-Set compaction: one + operational mechanism (clock sweep) and one protocol mechanisms (Map- + Versioning). Please note that in addition the Solicit-Map Request + (specified in [I-D.ietf-lisp-rfc6833bis]) is a control-plane + mechanisms that can be used to update EID-to-RLOC mappings. 13.1. Clock Sweep The clock sweep approach uses planning in advance and the use of count-down TTLs to time out mappings that have already been cached. The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, there is a 24-hour window to time out old mappings. The following clock sweep procedure is used: 1. 24 hours before a mapping change is to take effect, a network @@ -1454,110 +1367,34 @@ this 1-hour window, the ETRs continue to send Map-Reply messages with the current (unchanged) mapping records with the TTL set to 1 minute. 4. At the end of the 1-hour window, the ETRs will send Map-Reply messages with the new (changed) mapping records. So, any active caches can get the new mapping contents right away if not cached, or in 1 minute if they had the mapping cached. The new mappings are cached with a TTL equal to the TTL in the Map-Reply. -13.2. Solicit-Map-Request (SMR) - - Soliciting a Map-Request is a selective way for ETRs, at the site - 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. 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: - - 1. When the database mappings in an ETR change, the ETRs at the site - begin to send Map-Requests with the SMR bit set for each Locator - in each Map-Cache entry the ETR caches. - - 2. A remote ITR that receives the SMR message will schedule sending - a Map-Request message to the source locator address of the SMR - message or to the mapping database system. A newly allocated - random nonce is selected, and the EID-Prefix used is the one - copied from the SMR message. If the source Locator is the only - Locator in the cached Locator-Set, the remote ITR SHOULD send a - Map-Request to the database mapping system just in case the - single Locator has changed and may no longer be reachable to - accept the Map-Request. - - 3. The remote ITR MUST rate-limit the Map-Request until it gets a - Map-Reply while continuing to use the cached mapping. When - Map-Versioning as described in Section 13.3 is used, an SMR - sender can detect if an ITR is using the most up-to-date database - mapping. - - 4. The ETRs at the site with the changed mapping will reply to the - Map-Request with a Map-Reply message that has a nonce from the - SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- - limited. This is important to avoid Map-Reply implosion. - - 5. The ETRs at the site with the changed mapping record the fact - that the site that sent the Map-Request has received the new - mapping data in the Map-Cache entry for the remote site so the - Locator-Status-Bits are reflective of the new mapping for packets - going to the remote site. The ETR then stops sending SMR - messages. - - For security reasons, an ITR MUST NOT process unsolicited Map- - Replies. To avoid Map-Cache entry corruption by a third party, a - sender of an SMR-based Map-Request MUST be verified. If an ITR - receives an SMR-based Map-Request and the source is not in the - Locator-Set for the stored Map-Cache entry, then the responding Map- - Request MUST be sent with an EID destination to the mapping database - system. Since the mapping database system is a more secure way to - reach an authoritative ETR, it will deliver the Map-Request to the - authoritative source of the mapping data. - - When an ITR receives an SMR-based Map-Request for which it does not - have a cached mapping for the EID in the SMR message, it may not send - an SMR-invoked Map-Request. This scenario can occur when an ETR - sends SMR messages to all Locators in the Locator-Set it has stored - in its map-cache but the remote ITRs that receive the SMR may not be - sending packets to the site. There is no point in updating the ITRs - until they need to send, in which case they will send Map-Requests to - obtain a Map-Cache entry. - -13.3. Database Map-Versioning +13.2. Database Map-Versioning When there is unidirectional packet flow between an ITR and ETR, and the EID-to-RLOC mappings change on the ETR, it needs to inform the ITR so encapsulation to a removed Locator can stop and can instead be started to a new Locator in the Locator-Set. An ETR, when it sends Map-Reply messages, conveys its own Map-Version Number. This is known as the Destination Map-Version Number. ITRs include the Destination Map-Version Number in packets they encapsulate to the site. When an ETR decapsulates a packet and detects that the Destination Map-Version Number is less than the current version for its mapping, the SMR procedure described in - Section 13.2 occurs. + [I-D.ietf-lisp-rfc6833bis] occurs. An ITR, when it encapsulates packets to ETRs, can convey its own Map- Version Number. This is known as the Source Map-Version Number. When an ETR decapsulates a packet and detects that the Source Map- Version Number is greater than the last Map-Version Number sent in a Map-Reply from the ITR's site, the ETR will send a Map-Request to one of the ETRs for the source site. A Map-Version Number is used as a sequence number per EID-Prefix, so values that are greater are considered to be more recent. A value of @@ -2052,71 +1888,40 @@ 2017. [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, . - [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, - . - [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 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, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, 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, . - - [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", - RFC 5944, DOI 10.17487/RFC5944, November 2010, - . - [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . - [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, - . - - [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, - . - [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 [AFN] IANA, "Address Family Numbers", August 2016, . @@ -2146,50 +1951,50 @@ RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in progress), November 2017. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 (work in progress), October 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", - draft-ietf-lisp-signal-free-multicast-07 (work in - progress), November 2017. + draft-ietf-lisp-signal-free-multicast-08 (work in + progress), February 2018. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in progress), November 2017. - [I-D.ietf-opsec-icmp-filtering] - Gont, F., Gont, G., and C. Pignataro, "Recommendations for - filtering ICMP messages", draft-ietf-opsec-icmp- - filtering-04 (work in progress), July 2013. - - [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. - [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, . + [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, + . + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 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, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced @@ -2200,30 +2005,39 @@ A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [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, . + [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, . + [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, 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, . + [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", + RFC 5944, DOI 10.17487/RFC5944, 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, . [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, . @@ -2252,39 +2066,51 @@ Separation Protocol (LISP) MIB", RFC 7052, DOI 10.17487/RFC7052, October 2013, . [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, + . + [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 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, . + [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, + . + 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 @@ -2316,57 +2142,72 @@ 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-09 +B.1. 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 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.2. Changes to draft-ietf-lisp-rfc6830bis-08 +B.3. 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.3. Changes to draft-ietf-lisp-rfc6830bis-07 +B.4. 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.4. Changes to draft-ietf-lisp-rfc6830bis-06 +B.5. 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". @@ -2375,61 +2216,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.5. Changes to draft-ietf-lisp-rfc6830bis-05 +B.6. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. -B.6. Changes to draft-ietf-lisp-rfc6830bis-04 +B.7. 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.7. Changes to draft-ietf-lisp-rfc6830bis-03 +B.8. 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.8. Changes to draft-ietf-lisp-rfc6830bis-02 +B.9. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.9. Changes to draft-ietf-lisp-rfc6830bis-01 +B.10. 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.10. Changes to draft-ietf-lisp-rfc6830bis-00 +B.11. 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