--- 1/draft-ietf-lisp-rfc6830bis-03.txt 2017-07-17 17:13:09.326200511 -0700 +++ 2/draft-ietf-lisp-rfc6830bis-04.txt 2017-07-17 17:13:09.438203183 -0700 @@ -1,22 +1,22 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: November 3, 2017 D. Lewis +Expires: January 18, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - May 2, 2017 + July 17, 2017 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-03 + draft-ietf-lisp-rfc6830bis-04 Abstract This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. The @@ -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 November 3, 2017. + This Internet-Draft will expire on January 18, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -103,24 +103,25 @@ 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 - B.1. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 - B.2. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 - B.3. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 - B.4. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 + B.1. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 + B.2. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 + B.3. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52 + B.4. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52 + B.5. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 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 @@ -173,21 +174,21 @@ connects. Typically, each block is a sub-block of a service provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and is aggregated into the larger block before being advertised into the global Internet. Traditionally, IP multihoming has been implemented by each multihomed site acquiring its own globally visible prefix. LISP uses only topologically assigned and aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable practice. Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 - [RFC2460] address of an Egress Tunnel Router (ETR). An RLOC is + [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is the output of an EID-to-RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as PA addresses. Multiple RLOCs can be assigned to the same ETR device or to multiple ETR devices at a site. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of @@ -716,21 +718,21 @@ ^ + Destination EID + \ | | \ + + \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3. Tunnel Header Field Descriptions Inner Header (IH): The inner header is the header on the datagram received from the originating host. The source and destination IP - addresses are EIDs [RFC0791] [RFC2460]. + addresses are EIDs [RFC0791] [RFC8200]. Outer Header: (OH) The outer header is a new header prepended by an ITR. The address fields contain RLOCs obtained from the ingress router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" from [RFC0768]. The setting of the Don't Fragment (DF) bit 'Flags' field is according to rules listed in Sections 7.1 and 7.2. UDP Header: The UDP header contains an ITR selected source port when encapsulating a packet. See Section 12 for details on the hash @@ -743,24 +745,22 @@ [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is received by an ETR, the ETR MUST accept the packet for decapsulation. When an ITR transmits a non-zero value for the UDP checksum, it MUST send a correctly computed value in this field. When an ETR receives a packet with a non-zero UDP checksum, it MAY choose to verify the checksum value. If it chooses to perform such verification, and the verification fails, the packet MUST be silently dropped. If the ETR chooses not to perform the verification, or performs the verification successfully, the packet MUST be accepted for decapsulation. The handling of UDP - checksums for all tunneling protocols, including LISP, is under - active discussion within the IETF. When that discussion - concludes, any necessary changes will be made to align LISP with - the outcome of the broader discussion. + zero checksums over IPv6 for all tunneling protocols, including + LISP, is subject to the applicability statement in [RFC6936]. UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated packet to be the sum of the inner-header IPv4 Total Length plus the UDP and LISP header lengths. For an IPv6-encapsulated packet, the 'UDP Length' field is the sum of the inner-header IPv6 Payload Length, the size of the IPv6 header (40 octets), and the size of the UDP and LISP headers. N: The N-bit is the nonce-present bit. When this bit is set to 1, the low-order 24 bits of the first 32 bits of the LISP header @@ -2083,21 +2083,21 @@ [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-03 (work in progress), April + draft-ietf-lisp-rfc6833bis-05 (work in progress), May 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, . @@ -2113,24 +2113,20 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November 1998, . - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, - 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, . [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, January 2002, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, @@ -2142,21 +2138,21 @@ (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, . [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, + IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, DOI 10.17487/RFC5496, March 2009, . [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, @@ -2206,43 +2202,48 @@ [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . + [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, . [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1999, . [I-D.farinacci-lisp-predictive-rlocs] Farinacci, D. and P. Pillay-Esnault, "LISP Predictive - RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in - progress), November 2016. + RLOCs", draft-farinacci-lisp-predictive-rlocs-02 (work in + progress), May 2017. [I-D.ietf-lisp-mn] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", draft-ietf-lisp-mn-00 (work in progress), April 2017. [I-D.ietf-lisp-signal-free-multicast] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", - draft-ietf-lisp-signal-free-multicast-03 (work in - progress), April 2017. + draft-ietf-lisp-signal-free-multicast-04 (work in + progress), May 2017. [I-D.meyer-loc-id-implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", draft-meyer-loc-id-implications-01 (work in progress), January 2009. [I-D.portoles-lisp-eid-mobility] Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Control Plane", draft-portoles-lisp-eid- @@ -2376,61 +2377,70 @@ 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-03 +B.1. Changes to draft-ietf-lisp-rfc6830bis-04 + + o Posted July 2017. + + o Changed reference of IPv6 RFC2460 to RFC8200. + + o Indicate that the applicability statement for UDP zero checksums + over IPv6 adheres to RFC6936. + +B.2. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. -B.2. Changes to draft-ietf-lisp-rfc6830bis-02 +B.3. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.3. Changes to draft-ietf-lisp-rfc6830bis-01 +B.4. 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.4. Changes to draft-ietf-lisp-rfc6830bis-00 +B.5. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses - Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com + Vince Fuller Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: vince.fuller@gmail.com Dave Meyer Cisco Systems