--- 1/draft-ietf-lisp-rfc6830bis-01.txt 2017-04-11 11:13:32.137748023 -0700 +++ 2/draft-ietf-lisp-rfc6830bis-02.txt 2017-04-11 11:13:32.249750746 -0700 @@ -1,28 +1,28 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: September 27, 2017 D. Lewis +Expires: October 13, 2017 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - March 26, 2017 + April 11, 2017 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-01 + draft-ietf-lisp-rfc6830bis-02 Abstract - This document describes the Locator/ID Separation Protocol (LISP) - data-plane encapsulation protocol. LISP defines two namespaces, End- - point Identifiers (EIDs) that identify end-hosts and Routing Locators + 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 map-cache is populated by the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. @@ -35,21 +35,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 http://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 27, 2017. + This Internet-Draft will expire on October 13, 2017. 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 publication of this document. Please review these documents @@ -73,68 +73,69 @@ 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 20 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 21 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 22 8. Using Virtualization and Segmentation with LISP . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 23 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 29 - 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 - 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 + 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 . . . . . . . . . . . . . . . . 33 + 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 34 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 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 . . . . . . . . 37 - 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 + 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 . . . . . . . . . . . . . . 39 + 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40 - 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 + 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 41 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 - 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 + 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 - 21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 44 + 21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 45 21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 45 21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 45 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 22.1. Normative References . . . . . . . . . . . . . . . . . . 45 22.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 52 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 52 - B.1. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 - B.2. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 + B.1. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 + B.2. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 + B.3. 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 attachment points. LISP then defines functions for mapping between - the two numbering spaces and for encapsulating traffic originated by + the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. LISP is an overlay protocol that separates control from data-plane, this document specifies the data-plane, how LISP-capable routers (Tunnel Routers) exchange packets by encapsulating them to the appropriate location. Tunnel routers are equipped with a cache, called map-cache, that contains EID-to-RLOC mappings. The map-cache is populated using the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. @@ -142,25 +143,25 @@ LISP does not require changes to either host protocol stack or to underlay routers. By separating the EID from the RLOC space, LISP offers native Traffic Engineering, multihoming and mobility, among other features. Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]) This document specifies the LISP data-plane encapsulation and other - xTR functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP - control plane. LISP deployment guidelines can be found in [RFC7215] - and [RFC6835] describes considerations for network operational - management. Finally, [I-D.ietf-lisp-introduction] describes the LISP - architecture. + LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] + specifies the LISP control plane. LISP deployment guidelines can be + found in [RFC7215] and [RFC6835] describes considerations for network + operational management. Finally, [I-D.ietf-lisp-introduction] + describes the LISP architecture. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definition of Terms Provider-Independent (PI) Addresses: PI addresses are an address @@ -606,21 +607,22 @@ information about additional RLOCs SHOULD be verified by sending a LISP Map-Request for that EID. Both the ITR and the ETR may also influence the decision the other makes in selecting an RLOC. 5. LISP Encapsulation Details Since additional tunnel headers are prepended, the packet becomes larger and can exceed the MTU of any link traversed from the ITR to the ETR. It is RECOMMENDED in IPv4 that packets do not get fragmented as they are encapsulated by the ITR. Instead, the packet - is dropped and an ICMP Too Big message is returned to the source. + is dropped and an ICMP Unreachable/Fragmentation-Needed message is + returned to the source. This specification RECOMMENDS that implementations provide support for one of the proposed fragmentation and reassembly schemes. Two existing schemes are detailed in Section 7. Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner header is in IPv4 packet format and the outer header is in IPv6 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header is in IPv6 packet format and the outer header is in IPv4 packet @@ -977,22 +979,23 @@ then forwards each fragment to the destination host of the destination site. The two fragments are reassembled at the destination host into the single IP datagram that was originated by the source host. Note that reassembly can happen at the ETR if the encapsulated packet was fragmented at or after the ITR. This behavior is performed by the ITR when the source host originates a packet with the 'DF' field of the IP header set to 0. When the 'DF' field of the IP header is set to 1, or the packet is an IPv6 packet originated by the source host, the ITR will drop the packet - when the size is greater than L and send an ICMP Too Big message to - the source with a value of S, where S is (L - H). + when the size is greater than L and send an ICMP Unreachable/ + Fragmentation-Needed message to the source with a value of S, where S + is (L - H). When the outer-header encapsulation uses an IPv4 header, an implementation SHOULD set the DF bit to 1 so ETR fragment reassembly can be avoided. An implementation MAY set the DF bit in such headers to 0 if it has good reason to believe there are unresolvable path MTU issues between the sending ITR and the receiving ETR. This specification RECOMMENDS that L be defined as 1500. 7.2. A Stateful Solution to MTU Handling @@ -1000,32 +1003,33 @@ An ITR stateful solution to handle MTU issues is described as follows and was first introduced in [OPENLISP]: 1. The ITR will keep state of the effective MTU for each Locator per Map-Cache entry. The effective MTU is what the core network can deliver along the path between the ITR and ETR. 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet with the DF bit set to 1, exceeds what the core network can deliver, one of the intermediate routers on the path will send an - ICMP Too Big message to the ITR. The ITR will parse the ICMP - message to determine which Locator is affected by the effective - MTU change and then record the new effective MTU value in the - Map-Cache entry. + ICMP Unreachable/Fragmentation-Needed message to the ITR. The + ITR will parse the ICMP message to determine which Locator is + affected by the effective MTU change and then record the new + effective MTU value in the Map-Cache entry. 3. When a packet is received by the ITR from a source inside of the site and the size of the packet is greater than the effective MTU stored with the Map-Cache entry associated with the destination - EID the packet is for, the ITR will send an ICMP Too Big message - back to the source. The packet size advertised by the ITR in the - ICMP Too Big message is the effective MTU minus the LISP - encapsulation length. + EID the packet is for, the ITR will send an ICMP Unreachable/ + Fragmentation-Needed message back to the source. The packet size + advertised by the ITR in the ICMP Unreachable/Fragmentation- + Needed message is the effective MTU minus the LISP encapsulation + length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP When multiple organizations inside of a LISP site are using private addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain segregated due to possible address duplication. An Instance ID in @@ -2131,22 +2133,22 @@ [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-00 (work in progress), December - 2016. + draft-ietf-lisp-rfc6833bis-01 (work in progress), March + 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. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . @@ -2287,21 +2289,21 @@ [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-01 (work in progress), October 2016. + 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", @@ -2424,33 +2426,39 @@ 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-01 +B.1. Changes to draft-ietf-lisp-rfc6830bis-02 + + o Posted April 2017. + + o Reflect some editorial comments from Damien Sausez. + +B.2. 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.2. Changes to draft-ietf-lisp-rfc6830bis-00 +B.3. 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