idnits 2.17.1 draft-ietf-lisp-gpe-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2018) is 2082 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-lisp-6834bis-00 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Maino, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Lemon 5 Expires: February 16, 2019 Broadcom 6 P. Agarwal 7 Innovium 8 D. Lewis 9 M. Smith 10 Cisco 11 August 15, 2018 13 LISP Generic Protocol Extension 14 draft-ietf-lisp-gpe-05 16 Abstract 18 This document describes extentions to the Locator/ID Separation 19 Protocol (LISP) Data-Plane, via changes to the LISP header, to 20 support multi-protocol encapsulation. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 16, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 59 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 60 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 3 61 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 62 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR 63 Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Type of Service . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 6 68 5.2. Multiple Data-Planes Encapsulation Bitmap Registry . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 7. Acknowledgements and Contributors . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It 79 specifies an encapsulation format that carries IPv4 or IPv6 packets 80 (henceforth jointly referred to as IP) in a LISP header and outer 81 UDP/IP transport. 83 The LISP Data-Plane header does not specify the protocol being 84 encapsulated and therefore is currently limited to encapsulating only 85 IP packet payloads. Other protocols, most notably Virtual eXtensible 86 Local Area Network (VXLAN) [RFC7348] (which defines a similar header 87 format to LISP), are used to encapsulate Layer-2 (L2) protocols such 88 as Ethernet. 90 This document defines an extension for the LISP header, as defined in 91 [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling 92 the encapsulation of Ethernet, IP or any other desired protocol all 93 the while ensuring compatibility with existing LISP deployments. 95 A flag in the LISP header, called the P-bit, is used to signal the 96 presence of the 8-bit Next Protocol field. The Next Protocol field, 97 when present, uses 8 bits of the field allocated to the echo-noncing 98 and map-versioning features. The two features are still available, 99 albeit with a reduced length of Nonce and Map-Version. 101 1.1. Conventions 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 1.2. Definition of Terms 111 This document uses terms already defined in 112 [I-D.ietf-lisp-rfc6830bis]. 114 2. LISP Header Without Protocol Extensions 116 As described in Section 1, the LISP header has no protocol identifier 117 that indicates the type of payload being carried. Because of this, 118 LISP is limited to carrying IP payloads. 120 The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags 121 (some defined, some reserved), a Nonce/Map-version field and an 122 instance ID/Locator-status-bit field. The flags provide flexibility 123 to define how the various fields are encoded. Notably, Flag bit 5 is 124 the last reserved bit in the LISP header. 126 0 1 2 3 127 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Instance ID/Locator-Status-Bits | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 1: LISP Header 136 3. Generic Protocol Extension for LISP (LISP-GPE) 138 This document defines two changes to the LISP header in order to 139 support multi-protocol encapsulation: the introduction of the P-bit 140 and the definition of a Next Protocol field. This is shown in 141 Figure 2 and described below. 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Instance ID/Locator-Status-Bits | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 2: LISP-GPE Header 153 P-Bit: Flag bit 5 is defined as the Next Protocol bit. 155 If the P-bit is clear (0) the LISP header conforms to the 156 definition in [I-D.ietf-lisp-rfc6830bis]. 158 The P-bit is set to 1 to indicate the presence of the 8 bit Next 159 Protocol field. 161 Nonce/Map-Version: In [I-D.ietf-lisp-6834bis], LISP uses the lower 162 24 bits of the first word for a nonce, an echo-nonce, or to 163 support map- versioning. These are all optional capabilities that 164 are indicated in the LISP header by setting the N, E, and V bits 165 respectively. 167 When the P-bit and the N-bit are set to 1, the Nonce field is the 168 middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note that 169 the E-bit only has meaning when the N-bit is set. 171 When the P-bit and the V-bit are set to 1, the Version fields use 172 the middle 16 bits: the Source Map-Version uses the high-order 8 173 bits, and the Dest Map-Version uses the low-order 8 bits. 175 When the P-bit is set to 1 and the N-bit and the V-bit are both 0, 176 the middle 16-bits MUST be set to 0 on transmission and ignored on 177 receipt. 179 The encoding of the Nonce field in LISP-GPE, compared with the one 180 used in [I-D.ietf-lisp-rfc6830bis] for the LISP data plane 181 encapsulation, reduces the length of the nonce from 24 to 16 bits. 182 As per [I-D.ietf-lisp-rfc6830bis], Ingress Tunnel Routers (ITRs) 183 are required to generate different nonces when sending to 184 different Routing Locators (RLOCs), but the same nonce can be used 185 for a period of time when encapsulating to the same Egress Tunnel 186 Router (ETR). The use of 16 bits nonces still allows an ITR to 187 determine to and from reachability for up to 64k RLOCs at the same 188 time. 190 Similarly, the encoding of the Source and Dest Map-Version fields, 191 compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8 192 bits. This still allows to associate 256 different versions to 193 each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping 194 to inform commmunicating ITRs and ETRs about modifications of the 195 mapping. 197 Next Protocol: The lower 8 bits of the first 32-bit word are used to 198 carry a Next Protocol. This Next Protocol field contains the 199 protocol of the encapsulated payload packet. 201 This document defines the following Next Protocol values: 203 0x1 : IPv4 205 0x2 : IPv6 207 0x3 : Ethernet 209 0x4 : Network Service Header (NSH) [RFC8300] 211 The values are tracked in an IANA registry as described in 212 Section 5.1. 214 4. Backward Compatibility 216 LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 218 The next Section describes a method to determine the Data-Plane 219 capabilities of a LISP ETR, based on the use of the "Multiple Data- 220 Planes" LISP Canonical Address Format (LCAF) type defined in 221 [RFC8060]. Other mechanisms can be used, including static ETR/ITR 222 (xTR) configuration, but are out of the scope of this document. 224 When encapsulating IP packets to a non LISP-GPE capable router the 225 P-bit MUST be set to 0. That is, the encapsulation format defined in 226 this document MUST NOT be sent to a router that has not indicated 227 that it supports this specification because such a router would 228 ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so 229 would misinterpret the other LISP header fields possibly causing 230 significant errors. 232 A LISP-GPE router MUST NOT encapsulate non-IP packets to a non LISP- 233 GPE capable router. 235 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities 237 LISP Canonical Address Format (LCAF) [RFC8060] defines the "Multiple 238 Data-Planes" LCAF type, that can be included by an ETR in a Map-Reply 239 to encode the encapsulation formats supported by a given RLOC. In 240 this way an ITR can be made aware of the capability to support LISP- 241 GPE, as well as other encapsulations, on a given RLOC of that ETR. 243 The 3rd 32-bit word of the "Multiple Data-Planes" LCAF type, as 244 defined in [RFC8060], is a bitmap whose bits are set to one (1) to 245 represent support for each Data-Plane encapsulation. The values are 246 tracked in an IANA registry as described in Section 5.2. 248 This document defines bit 24 in the third 32-bit word of the 249 "Multiple Data-Planes" LCAF as: 251 g-Bit: The RLOCs listed in the Address Family Identifier (AFI) 252 encoded addresses in the next longword can accept LISP-GPE 253 (Generic Protocol Extension) encapsulation using destination UDP 254 port 4341 256 4.2. Type of Service 258 When a LISP-GPE router performs Ethernet encapsulation, the inner 259 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 260 mapped from the encapsulated frame to the Type of Service field in 261 the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 262 field 264 4.3. VLAN Identifier (VID) 266 When a LISP-GPE router performs Ethernet encapsulation, the inner 267 header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped 268 to, or used to determine the LISP Instance IDentifier (IID) field. 270 5. IANA Considerations 272 5.1. LISP-GPE Next Protocol Registry 274 IANA is requested to set up a registry of LISP-GPE "Next Protocol". 275 These are 8-bit values. Next Protocol values in the table below are 276 defined in this document. New values are assigned via Standards 277 Action [RFC8126]. The protocols that are being assigned values do 278 not themselves need to be IETF standards track protocols. 280 +---------------+-------------+---------------+ 281 | Next Protocol | Description | Reference | 282 +---------------+-------------+---------------+ 283 | 0 | Reserved | This Document | 284 | 1 | IPv4 | This Document | 285 | 2 | IPv6 | This Document | 286 | 3 | Ethernet | This Document | 287 | 4 | NSH | This Document | 288 | 5..255 | Unassigned | | 289 +---------------+-------------+---------------+ 291 5.2. Multiple Data-Planes Encapsulation Bitmap Registry 293 IANA is requested to set up a registry of "Multiple Data-Planes 294 Encapsulation Bitmap" to identify the encapsulations supported by an 295 ETR in the Multiple Data-Planes LCAF Type defined in [RFC8060]. The 296 bitmap is the 3rd 32-bit word of the Multiple Data-Planes LCAF type. 297 Each bit of the bitmap represents a Data-Plane Encapsulation. New 298 values are assigned via Standards Action [RFC8126]. 300 Bits 0-23 are unassigned. This document assigns bit 24 (g-bit) to 301 LISP-GPE. Bits 25-31 are assigned in [RFC8060]). 303 +----------+-------+------------------------------------+-----------+ 304 | Bit | Bit | Assigned to | Reference | 305 | Position | Name | | | 306 +----------+-------+------------------------------------+-----------+ 307 | 0-23 | | Unassigned | | 308 | 24 | g | LISP Generic Protocol Extension | This | 309 | | | (LISP-GPE) | Document | 310 | 25 | U | Generic UDP Encapsulation (GUE) | [RFC8060] | 311 | 26 | G | Generic Network Virtualization | [RFC8060] | 312 | | | Encapsulation (GENEVE) | | 313 | 27 | N | Network Virtualization - Generic | [RFC8060] | 314 | | | Routing Encapsulation (NV-GRE) | | 315 | 28 | v | VXLAN Generic Protocol Extension | [RFC8060] | 316 | | | (VXLAN-GPE) | | 317 | 29 | V | Virtual eXtensible Local Area | [RFC8060] | 318 | | | Network (VXLAN) | | 319 | 30 | l | Layer 2 LISP (LISP-L2) | [RFC8060] | 320 | 31 | L | Locator/ID Separation Protocol | [RFC8060] | 321 | | | (LISP) | | 322 +----------+-------+------------------------------------+-----------+ 324 6. Security Considerations 326 LISP-GPE security considerations are similar to the LISP security 327 considerations and mitigation techniques documented in [RFC7835]. 329 With LISP-GPE, issues such as data-plane spoofing, flooding, and 330 traffic redirection may depend on the particular protocol payload 331 encapsulated. 333 7. Acknowledgements and Contributors 335 A special thank you goes to Dino Farinacci for his guidance and 336 detailed review. 338 This Workking Group (WG) document originated as draft-lewis-lisp-gpe; 339 the following are its coauthors and contributors along with their 340 respective affiliations at the time of WG adoption. The editor of 341 this document would like to thank and recognize them and their 342 contributions. These coauthors and contributors provided invaluable 343 concepts and content for this document's creation. 345 o Darrel Lewis, Cisco Systems, Inc. 347 o Fabio Maino, Cisco Systems, Inc. 349 o Paul Quinn, Cisco Systems, Inc. 351 o Michael Smith, Cisco Systems, Inc. 353 o Navindra Yadav, Cisco Systems, Inc. 355 o Larry Kreeger 357 o John Lemon, Broadcom 359 o Puneet Agarwal, Innovium 361 8. References 363 8.1. Normative References 365 [I-D.ietf-lisp-6834bis] 366 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 367 Separation Protocol (LISP) Map-Versioning", draft-ietf- 368 lisp-6834bis-00 (work in progress), July 2018. 370 [I-D.ietf-lisp-rfc6830bis] 371 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 372 Cabellos-Aparicio, "The Locator/ID Separation Protocol 373 (LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress), 374 July 2018. 376 [IEEE.802.1Q_2014] 377 IEEE, "IEEE Standard for Local and metropolitan area 378 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 379 DOI 10.1109/ieeestd.2014.6991462, December 2014, 380 . 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, . 388 8.2. Informative References 390 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 391 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 392 eXtensible Local Area Network (VXLAN): A Framework for 393 Overlaying Virtualized Layer 2 Networks over Layer 3 394 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 395 . 397 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 398 Separation Protocol (LISP) Threat Analysis", RFC 7835, 399 DOI 10.17487/RFC7835, April 2016, . 402 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 403 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 404 February 2017, . 406 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 407 Writing an IANA Considerations Section in RFCs", BCP 26, 408 RFC 8126, DOI 10.17487/RFC8126, June 2017, 409 . 411 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 412 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 413 May 2017, . 415 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 416 "Network Service Header (NSH)", RFC 8300, 417 DOI 10.17487/RFC8300, January 2018, . 420 Authors' Addresses 422 Fabio Maino (editor) 423 Cisco Systems 424 San Jose, CA 95134 425 USA 427 Email: fmaino@cisco.com 429 John Lemon 430 Broadcom 431 270 Innovation Drive 432 San Jose, CA 95134 433 USA 435 Email: john.lemon@broadcom.com 437 Puneet Agarwal 438 Innovium 439 USA 441 Email: puneet@acm.org 443 Darrel Lewis 444 Cisco Systems 446 Email: darlewis@cisco.com 448 Michael Smith 449 Cisco Systems 451 Email: michsmit@cisco.com