idnits 2.17.1 draft-ietf-lisp-gpe-19.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 (July 26, 2020) is 1370 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 (-38) exists of draft-ietf-lisp-rfc6830bis-32 == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-vxlan-gpe-03 == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-ecn-encap-guidelines-13 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: January 27, 2021 Broadcom 6 P. Agarwal 7 Innovium 8 D. Lewis 9 M. Smith 10 Cisco 11 July 26, 2020 13 LISP Generic Protocol Extension 14 draft-ietf-lisp-gpe-19 16 Abstract 18 This document describes extensions to the Locator/ID Separation 19 Protocol (LISP) Data-Plane, via changes to the LISP header, to 20 support multi-protocol encapsulation and allow to introduce new 21 protocol capabilities. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 27, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 60 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 61 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 62 4. Implementation and Deployment Considerations . . . . . . . . 6 63 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6 64 4.2. Congestion Control Functionality . . . . . . . . . . . . 7 65 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 67 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10 68 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 69 5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 9.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It 82 specifies an encapsulation format that carries IPv4 or IPv6 packets 83 (henceforth jointly referred to as IP) in a LISP header and outer 84 UDP/IP transport. 86 The LISP Data-Plane header does not specify the protocol being 87 encapsulated and therefore is currently limited to encapsulating only 88 IP packet payloads. Other protocols, most notably Virtual eXtensible 89 Local Area Network (VXLAN) [RFC7348] (which defines a similar header 90 format to LISP), are used to encapsulate Layer-2 (L2) protocols such 91 as Ethernet. 93 This document defines an extension for the LISP header, as defined in 94 [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling 95 the encapsulation of Ethernet, IP or any other desired protocol all 96 the while ensuring compatibility with existing LISP deployments. 98 A flag in the LISP header, called the P-bit, is used to signal the 99 presence of the 8-bit Next Protocol field. The Next Protocol field, 100 when present, uses 8 bits of the field that was allocated to the 101 echo-noncing and map-versioning features in 102 [I-D.ietf-lisp-rfc6830bis]. Those two features are no longer 103 available when the P-bit is used. However, appropriate LISP-GPE 104 (LISP Generic Protocol Extension) shim headers can be defined to 105 specify capabilities that are equivalent to echo-noncing and/or map- 106 versioning. 108 Since all of the reserved bits of the LISP Data-Plane header have 109 been allocated, LISP-GPE can also be used to extend the LISP Data- 110 Plane header by defining Next Protocol "shim" headers that implements 111 new data plane functions not supported in the LISP header. For 112 example, the use of the Group-Based Policy (GBP) header 113 [I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations, 114 Administration, and Maintenance (IOAM) header 115 [I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered 116 an extension to add support in the Data-Plane for Group-Based Policy 117 functionalities or IOAM metadata. 119 1.1. Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 1.2. Definition of Terms 129 This document uses terms already defined in 130 [I-D.ietf-lisp-rfc6830bis]. 132 2. LISP Header Without Protocol Extensions 134 As described in Section 1, the LISP header has no protocol identifier 135 that indicates the type of payload being carried. Because of this, 136 LISP is limited to carrying IP payloads. 138 The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags 139 (some defined, some reserved), a Nonce/Map-version field and an 140 instance ID/Locator-status-bit field. The flags provide flexibility 141 to define how the various fields are encoded. Notably, Flag bit 5 is 142 the last reserved bit in the LISP header. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Instance ID/Locator-Status-Bits | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: LISP Header 154 3. Generic Protocol Extension for LISP (LISP-GPE) 156 This document defines two changes to the LISP header in order to 157 support multi-protocol encapsulation: the introduction of the P-bit 158 and the definition of a Next Protocol field. This document specifies 159 the protocol behavior when the P-bit is set to 1, no changes are 160 introduced when the P-bit is set to 0. The LISP-GPE header is shown 161 in Figure 2 and described below. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |N|L|E|V|I|P|K|K| Nonce/Map-Version/Next Protocol | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Instance ID/Locator-Status-Bits | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 2: LISP-GPE Header 173 P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is 174 set to 1 to indicate the presence of the 8 bit Next Protocol 175 field. 177 If the P-bit is clear (0) the LISP header is bit-by-bit equivalent 178 to the definition in [I-D.ietf-lisp-rfc6830bis]. 180 When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the 181 'Nonce/Map-Version/Next Protocol' field MUST be set to zero on 182 transmission and MUST be ignored on receipt. Features equivalent 183 to those that were implemented with bits N,E and V in 184 [I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map- 185 versioning, can be implemented by defining appropriate LISP-GPE 186 shim headers. 188 When the P-bit is set to 1, the LISP-GPE header is encoded as: 190 0 x 0 0 x 1 x x 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |N|L|E|V|I|P|K|K| 0x0000 | Next Protocol | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Instance ID/Locator-Status-Bits | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 3: LISP-GPE with P-bit set to 1 199 Next Protocol: When the P-bit is set to 1, the lower 8 bits of the 200 first 32-bit word are used to carry a Next Protocol. This Next 201 Protocol field contains the protocol of the encapsulated payload 202 packet. 204 This document defines the following Next Protocol values: 206 0x00 : Reserved 208 0x01 : IPv4 210 0x02 : IPv6 212 0x03 : Ethernet 214 0x04 : Network Service Header (NSH) [RFC8300] 216 0x05 to 0x7D: Unassigned 218 0x7E, 0x7F: Experimentation and testing 220 0x80 to 0xFD: Unassigned (shim headers) 222 0xFE, 0xFF: Experimentation and testing (shim headers) 224 The values are tracked in the IANA LISP-GPE Next Protocol Registry 225 as described in Section 6.1. 227 Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for 228 experimentation and testing as per [RFC3692]. 230 Next protocol values from Ox80 to 0xFD are assigned to protocols 231 encoded as generic "shim" headers. All shim protocols MUST use the 232 header structure in Figure 4, which includes a Next Protocol field. 233 When shim headers are used with other protocols identified by next 234 protocol values from 0x00 to 0x7F, all the shim headers MUST come 235 first. 237 Shim headers can be used to incrementally deploy new GPE features, 238 keeping the processing of shim headers known to a given xTR 239 implementation in the 'fast' path (typically an ASIC), while punting 240 the processing of the remaining new GPE features to the 'slow' path. 242 Shim protocols MUST have the first 32 bits defined as: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length | Reserved | Next Protocol | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ Protocol Specific Fields ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 4: Shim Header 256 Where: 258 Type: This field identifies the different messages of this protocol. 260 Length: The length, in 4-octet units, of this protocol message not 261 including the first 4 octets. 263 Reserved: The use of this field is reserved to the protocol defined 264 in this message. 266 Next Protocol Field: The next protocol field contains the protocol 267 of the encapsulated payload. The values are tracked in the IANA 268 LISP-GPE Next Protocol Registry as described in Section 6.1. 270 4. Implementation and Deployment Considerations 272 4.1. Applicability Statement 274 LISP-GPE conforms, as an UDP-based encapsulation protocol, to the UDP 275 usage guidelines as specified in [RFC8085]. The applicability of 276 these guidelines are dependent on the underlay IP network and the 277 nature of the encapsulated payload. 279 [RFC8085] outlines two applicability scenarios for UDP applications, 280 1) general Internet and 2) controlled environment. The controlled 281 environment means a single administrative domain or adjacent set of 282 cooperating domains. A network in a controlled environment can be 283 managed to operate under certain conditions whereas in general 284 Internet this cannot be done. Hence requirements for a tunnel 285 protocol operating under a controlled environment can be less 286 restrictive than the requirements of general internet. 288 LISP-GPE scope of applicability is the same set of use cases covered 289 by[I-D.ietf-lisp-rfc6830bis] for the LISP dataplane protocol. The 290 common property of these use cases is a large set of cooperating 291 entities seeking to communicate over the public Internet or other 292 large underlay IP infrastructures, while keeping the addressing and 293 topology of the cooperating entities separate from the underlay and 294 Internet topology, routing, and addressing. 296 LISP-GPE is meant to be deployed in network environments operated by 297 a single operator or adjacent set of cooperating network operators 298 that fits with the definition of controlled environments in 299 [RFC8085]. 301 For the purpose of this document, a traffic-managed controlled 302 environment (TMCE), outlined in [RFC8086], is defined as an IP 303 network that is traffic-engineered and/or otherwise managed (e.g., 304 via use of traffic rate limiters) to avoid congestion. Significant 305 portions of text in this Section are based on [RFC8086]. 307 It is the responsibility of the network operators to ensure that the 308 guidelines/requirements in this section are followed as applicable to 309 their LISP-GPE deployments 311 4.2. Congestion Control Functionality 313 LISP-GPE does not natively provide congestion control functionality 314 and relies on the payload protocol traffic for congestion control. 315 As such LISP-GPE MUST be used with congestion controlled traffic or 316 within a network that is traffic managed to avoid congestion (TMCE). 317 An operator of a traffic managed network (TMCE) may avoid congestion 318 by careful provisioning of their networks, rate-limiting of user data 319 traffic and traffic engineering according to path capacity. 321 Keeping in mind the reccomendation above, new encapsulated payloads, 322 when registered with LISP-GPE, MUST be accompained by a set of 323 guidelines derived from [I-D.ietf-lisp-rfc6830bis]. Such new 324 protocols should be designed for explicit congestion signals to 325 propagate consistently from lower layer protocols into IP. Then the 326 IP internetwork layer can act as a portability layer to carry 327 congestion notification from non-IP-aware congested nodes up to the 328 transport layer (L4). By following the guidelines in 329 [I-D.ietf-tsvwg-ecn-encap-guidelines], subnetwork designers can 330 enable a layer-2 protocol to participate in congestion control 331 without dropping packets via propagation of explicit congestion 332 notification (ECN [RFC3168] ) to receivers. 334 4.3. UDP Checksum 336 For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies 337 how to handle UDP Checksums encouraging implementors to consider UDP 338 checksum usage guidelines in section 3.4 of [RFC8085] when it is 339 desirable to protect UDP and LISP headers against corruption. 341 In order to provide integrity of LISP-GPE headers, options and 342 payload, for example to avoid mis-delivery of payload to different 343 tenant systems in case of data corruption, outer UDP checksum SHOULD 344 be used with LISP-GPE when transported over IPv4. The UDP checksum 345 provides a statistical guarantee that a payload was not corrupted in 346 transit. These integrity checks are not strong from a coding or 347 cryptographic perspective and are not designed to detect physical- 348 layer errors or malicious modification of the datagram (see 349 Section 3.4 of [RFC8085]). In deployments where such a risk exists, 350 an operator SHOULD use additional data integrity mechanisms such as 351 offered by IPSec. 353 An operator MAY choose to disable UDP checksum and use zero checksum 354 if LISP-GPE packet integrity is provided by other data integrity 355 mechanisms such as IPsec or additional checksums or if one of the 356 conditions in Section 4.3.1 a, b, c are met. 358 4.3.1. UDP Zero Checksum Handling with IPv6 360 By default, UDP checksum MUST be used when LISP-GPE is transported 361 over IPv6. A tunnel endpoint MAY be configured for use with zero UDP 362 checksum if additional requirements described in this section are 363 met. 365 When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 366 headers, UDP headers and LISP-GPE headers and payload from potential 367 data corruption. As such by default LISP-GPE MUST use UDP checksum 368 when transported over IPv6. An operator MAY choose to configure to 369 operate with zero UDP checksum if operating in a traffic managed 370 controlled environment as stated in Section 4.1 if one of the 371 following conditions are met: 373 a. It is known that the packet corruption is exceptionally unlikely 374 (perhaps based on knowledge of equipment types in their underlay 375 network) and the operator is willing to take a risk of undetected 376 packet corruption 378 b. It is judged through observational measurements (perhaps through 379 historic or current traffic flows that use non zero checksum) 380 that the level of packet corruption is tolerably low and where 381 the operator is willing to take the risk of undetected corruption 383 c. LISP-GPE payload is carrying applications that are tolerant of 384 misdelivered or corrupted packets (perhaps through higher layer 385 checksum validation and/or reliability through retransmission) 387 In addition LISP-GPE tunnel implementations using Zero UDP checksum 388 MUST meet the following requirements: 390 1. Use of UDP checksum over IPv6 MUST be the default configuration 391 for all LISP-GPE tunnels 393 2. If LISP-GPE is used with zero UDP checksum over IPv6 then such 394 xTR implementation MUST meet all the requirements specified in 395 section 4 of [RFC6936] and requirements 1 as specified in section 396 5 of [RFC6936] 398 3. The ETR that decapsulates the packet SHOULD check the source and 399 destination IPv6 addresses are valid for the LISP-GPE tunnel that 400 is configured to receive Zero UDP checksum and discard other 401 packets for which such check fails 403 4. The ITR that encapsulates the packet MAY use different IPv6 404 source addresses for each LISP-GPE tunnel that uses Zero UDP 405 checksum mode in order to strengthen the decapsulator's check of 406 the IPv6 source address (i.e the same IPv6 source address is not 407 to be used with more than one IPv6 destination address, 408 irrespective of whether that destination address is a unicast or 409 multicast address). When this is not possible, it is RECOMMENDED 410 to use each source address for as few LISP-GPE tunnels that use 411 zero UDP checksum as is feasible 413 5. Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 414 with zero UDP checksum from escaping into the general Internet. 415 Examples of such measures include employing packet filters at the 416 PETR and/or keeping logical or physical separation of LISP 417 network from networks carrying General Internet 419 The above requirements do not change either the requirements 420 specified in [RFC2460] as modified by [RFC6935] or the requirements 421 specified in [RFC6936]. 423 The requirement to check the source IPv6 address in addition to the 424 destination IPv6 address, plus the recommendation against reuse of 425 source IPv6 addresses among LISP-GPE tunnels collectively provide 426 some mitigation for the absence of UDP checksum coverage of the IPv6 427 header. A traffic-managed controlled environment that satisfies at 428 least one of three conditions listed at the beginning of this section 429 provides additional assurance. 431 4.4. DSCP, ECN, TTL, and 802.1Q 433 When encapsulating IP (including over Ethernet) packets [RFC2983] 434 provides guidance for mapping DSCP between inner and outer IP 435 headers. The Pipe model typically fits better Network 436 virtualization. The DSCP value on the tunnel header is set based on 437 a policy (which may be a fixed value, one based on the inner traffic 438 class, or some other mechanism for grouping traffic). Some aspects 439 of the Uniform model (which treats the inner and outer DSCP value as 440 a single field by copying on ingress and egress) may also apply, such 441 as the ability to remark the inner header on tunnel egress based on 442 transit marking. However, the Uniform model is not conceptually 443 consistent with network virtualization, which seeks to provide strong 444 isolation between encapsulated traffic and the physical network. 446 [RFC6040] describes the mechanism for exposing ECN capabilities on IP 447 tunnels and propagating congestion markers to the inner packets. 448 This behavior MUST be followed for IP packets encapsulated in LISP- 449 GPE. 451 Though Uniform or Pipe models could be used for TTL (or Hop Limit in 452 case of IPv6) handling when tunneling IP packets, Pipe model is more 453 aligned with network virtualization. [RFC2003] provides guidance on 454 handling TTL between inner IP header and outer IP tunnels; this model 455 is more aligned with the Pipe model and is recommended for use with 456 LISP-GPE for network virtualization applications. 458 When a LISP-GPE router performs Ethernet encapsulation, the inner 459 802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY 460 be mapped from the encapsulated frame to the DSCP codepoint of the DS 461 field defined in [RFC2474]. 463 When a LISP-GPE router performs Ethernet encapsulation, the inner 464 header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped 465 to, or used to determine the LISP Instance IDentifier (IID) field. 467 Refer to Section 7 for consideration about the use of integrity 468 protection for deployments, such as the public Internet, concerned 469 with on-path attackers. 471 5. Backward Compatibility 473 LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 475 When encapsulating IP packets to a non LISP-GPE capable router the 476 P-bit MUST be set to 0. That is, the encapsulation format defined in 477 this document MUST NOT be sent to a router that has not indicated 478 that it supports this specification because such a router would 479 ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so 480 would misinterpret the other LISP header fields possibly causing 481 significant errors. 483 5.1. Detection of ETR Capabilities 485 The discovery of xTR capabilities to support LISP-GPE is out of the 486 scope of this document. Given that the applicability domain of LISP- 487 GPE is a traffic-managed controlled environment, ITR/ETR (xTR) 488 configuration mechanisms may be used for this purpose. 490 6. IANA Considerations 492 6.1. LISP-GPE Next Protocol Registry 494 IANA is requested to set up a registry of LISP-GPE "Next Protocol". 495 These are 8-bit values. Next Protocol values in the table below are 496 defined in this document. New values are assigned under the 497 Specification Required policy [RFC8126]. The protocols that are 498 being assigned values do not themselves need to be IETF standards 499 track protocols. 501 +--------------+-------------------------------------+--------------+ 502 | Next | Description | Reference | 503 | Protocol | | | 504 +--------------+-------------------------------------+--------------+ 505 | 0x0 | Reserved | This | 506 | | | Document | 507 | 0x1 | IPv4 | This | 508 | | | Document | 509 | 0x2 | IPv6 | This | 510 | | | Document | 511 | 0x3 | Ethernet | This | 512 | | | Document | 513 | 0x4 | NSH | This | 514 | | | Document | 515 | 0x05..0x7D | Unassigned | | 516 | 0x7E..0x7F | Experimentation and testing | This | 517 | | | Document | 518 | 0x80..0xFD | Unassigned (shim headers) | | 519 | 0x8E..0x8F | Experimentation and testing (shim | This | 520 | | headers) | Document | 521 +--------------+-------------------------------------+--------------+ 523 7. Security Considerations 525 LISP-GPE security considerations are similar to the LISP security 526 considerations and mitigation techniques documented in [RFC7835]. 528 LISP-GPE, as many encapsulations that use optional extensions, is 529 subject to on-path adversaries that can make arbitrary modifications 530 to the packet (including the P-Bit) to change or remove any part of 531 the payload, or claim to encapsulate any protocol payload type. 532 Typical integrity protection mechanisms (such as IPsec) SHOULD be 533 used in combination with LISP-GPE by those protocol extensions that 534 want to protect from on-path attackers. 536 With LISP-GPE, issues such as data-plane spoofing, flooding, and 537 traffic redirection may depend on the particular protocol payload 538 encapsulated. 540 8. Acknowledgements and Contributors 542 A special thank you goes to Dino Farinacci for his guidance and 543 detailed review. Thanks to Tom Herbert for the suggestion to assign 544 codepoints for experimentations and testing. 546 This Working Group (WG) document originated as draft-lewis-lisp-gpe; 547 the following are its coauthors and contributors along with their 548 respective affiliations at the time of WG adoption. The editor of 549 this document would like to thank and recognize them and their 550 contributions. These coauthors and contributors provided invaluable 551 concepts and content for this document's creation. 553 o Darrel Lewis, Cisco Systems, Inc. 555 o Fabio Maino, Cisco Systems, Inc. 557 o Paul Quinn, Cisco Systems, Inc. 559 o Michael Smith, Cisco Systems, Inc. 561 o Navindra Yadav, Cisco Systems, Inc. 563 o Larry Kreeger 565 o Jennifer Lemon, Broadcom 567 o Puneet Agarwal, Innovium 569 9. References 571 9.1. Normative References 573 [I-D.ietf-lisp-rfc6830bis] 574 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 575 Cabellos-Aparicio, "The Locator/ID Separation Protocol 576 (LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress), 577 March 2020. 579 [IEEE.802.1Q_2014] 580 IEEE, "IEEE Standard for Local and metropolitan area 581 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 582 DOI 10.1109/ieeestd.2014.6991462, December 2014, 583 . 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 592 Notification", RFC 6040, DOI 10.17487/RFC6040, November 593 2010, . 595 9.2. Informative References 597 [I-D.brockners-ippm-ioam-vxlan-gpe] 598 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 599 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., 600 Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 601 Encapsulation for In-situ OAM Data", draft-brockners-ippm- 602 ioam-vxlan-gpe-03 (work in progress), November 2019. 604 [I-D.ietf-tsvwg-ecn-encap-guidelines] 605 Briscoe, B., Kaippallimalil, J., and P. Thaler, 606 "Guidelines for Adding Congestion Notification to 607 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 608 encap-guidelines-13 (work in progress), May 2019. 610 [I-D.lemon-vxlan-lisp-gpe-gbp] 611 Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group 612 Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- 613 vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. 615 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 616 DOI 10.17487/RFC2003, October 1996, 617 . 619 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 620 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 621 December 1998, . 623 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 624 "Definition of the Differentiated Services Field (DS 625 Field) in the IPv4 and IPv6 Headers", RFC 2474, 626 DOI 10.17487/RFC2474, December 1998, 627 . 629 [RFC2983] Black, D., "Differentiated Services and Tunnels", 630 RFC 2983, DOI 10.17487/RFC2983, October 2000, 631 . 633 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 634 of Explicit Congestion Notification (ECN) to IP", 635 RFC 3168, DOI 10.17487/RFC3168, September 2001, 636 . 638 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 639 Considered Useful", BCP 82, RFC 3692, 640 DOI 10.17487/RFC3692, January 2004, 641 . 643 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 644 UDP Checksums for Tunneled Packets", RFC 6935, 645 DOI 10.17487/RFC6935, April 2013, 646 . 648 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 649 for the Use of IPv6 UDP Datagrams with Zero Checksums", 650 RFC 6936, DOI 10.17487/RFC6936, April 2013, 651 . 653 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 654 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 655 eXtensible Local Area Network (VXLAN): A Framework for 656 Overlaying Virtualized Layer 2 Networks over Layer 3 657 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 658 . 660 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 661 Separation Protocol (LISP) Threat Analysis", RFC 7835, 662 DOI 10.17487/RFC7835, April 2016, 663 . 665 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 666 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 667 March 2017, . 669 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 670 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 671 March 2017, . 673 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 674 Writing an IANA Considerations Section in RFCs", BCP 26, 675 RFC 8126, DOI 10.17487/RFC8126, June 2017, 676 . 678 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 679 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 680 May 2017, . 682 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 683 "Network Service Header (NSH)", RFC 8300, 684 DOI 10.17487/RFC8300, January 2018, 685 . 687 Authors' Addresses 689 Fabio Maino (editor) 690 Cisco Systems 691 San Jose, CA 95134 692 USA 694 Email: fmaino@cisco.com 696 Jennifer Lemon 697 Broadcom 698 270 Innovation Drive 699 San Jose, CA 95134 700 USA 702 Email: jennifer.lemon@broadcom.com 704 Puneet Agarwal 705 Innovium 706 USA 708 Email: puneet@acm.org 710 Darrel Lewis 711 Cisco Systems 712 San Jose, CA 95134 713 USA 715 Email: darlewis@cisco.com 717 Michael Smith 718 Cisco Systems 719 San Jose, CA 95134 720 USA 722 Email: michsmit@cisco.com