idnits 2.17.1 draft-ietf-lisp-gpe-18.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 13, 2020) is 1376 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 14, 2021 Broadcom 6 P. Agarwal 7 Innovium 8 D. Lewis 9 M. Smith 10 Cisco 11 July 13, 2020 13 LISP Generic Protocol Extension 14 draft-ietf-lisp-gpe-18 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 14, 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 . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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, should be designed for explicit 323 congestion signals to propagate consistently from lower layer 324 protocols into IP. Then the IP internetwork layer can act as a 325 portability layer to carry congestion notification from non-IP-aware 326 congested nodes up to the transport layer (L4). Such new 327 encapsulated payloads, when registered with LISP-GPE, MUST be 328 accompanied by a set of guidelines derived from [RFC6040] and SHOULD 329 follow the guidelines defined in 330 [I-D.ietf-tsvwg-ecn-encap-guidelines]. 332 4.3. UDP Checksum 334 For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies 335 how to handle UDP Checksums encouraging implementors to consider UDP 336 checksum usage guidelines in section 3.4 of [RFC8085] when it is 337 desirable to protect UDP and LISP headers against corruption. 339 In order to provide integrity of LISP-GPE headers, options and 340 payload, for example to avoid mis-delivery of payload to different 341 tenant systems in case of data corruption, outer UDP checksum SHOULD 342 be used with LISP-GPE when transported over IPv4. The UDP checksum 343 provides a statistical guarantee that a payload was not corrupted in 344 transit. These integrity checks are not strong from a coding or 345 cryptographic perspective and are not designed to detect physical- 346 layer errors or malicious modification of the datagram (see 347 Section 3.4 of [RFC8085]). In deployments where such a risk exists, 348 an operator SHOULD use additional data integrity mechanisms such as 349 offered by IPSec. 351 An operator MAY choose to disable UDP checksum and use zero checksum 352 if LISP-GPE packet integrity is provided by other data integrity 353 mechanisms such as IPsec or additional checksums or if one of the 354 conditions in Section 4.3.1 a, b, c are met. 356 4.3.1. UDP Zero Checksum Handling with IPv6 358 By default, UDP checksum MUST be used when LISP-GPE is transported 359 over IPv6. A tunnel endpoint MAY be configured for use with zero UDP 360 checksum if additional requirements described in this section are 361 met. 363 When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 364 headers, UDP headers and LISP-GPE headers and payload from potential 365 data corruption. As such by default LISP-GPE MUST use UDP checksum 366 when transported over IPv6. An operator MAY choose to configure to 367 operate with zero UDP checksum if operating in a traffic managed 368 controlled environment as stated in Section 4.1 if one of the 369 following conditions are met: 371 a. It is known that the packet corruption is exceptionally unlikely 372 (perhaps based on knowledge of equipment types in their underlay 373 network) and the operator is willing to take a risk of undetected 374 packet corruption 376 b. It is judged through observational measurements (perhaps through 377 historic or current traffic flows that use non zero checksum) 378 that the level of packet corruption is tolerably low and where 379 the operator is willing to take the risk of undetected corruption 381 c. LISP-GPE payload is carrying applications that are tolerant of 382 misdelivered or corrupted packets (perhaps through higher layer 383 checksum validation and/or reliability through retransmission) 385 In addition LISP-GPE tunnel implementations using Zero UDP checksum 386 MUST meet the following requirements: 388 1. Use of UDP checksum over IPv6 MUST be the default configuration 389 for all LISP-GPE tunnels 391 2. If LISP-GPE is used with zero UDP checksum over IPv6 then such 392 xTR implementation MUST meet all the requirements specified in 393 section 4 of [RFC6936] and requirements 1 as specified in section 394 5 of [RFC6936] 396 3. The ETR that decapsulates the packet SHOULD check the source and 397 destination IPv6 addresses are valid for the LISP-GPE tunnel that 398 is configured to receive Zero UDP checksum and discard other 399 packets for which such check fails 401 4. The ITR that encapsulates the packet MAY use different IPv6 402 source addresses for each LISP-GPE tunnel that uses Zero UDP 403 checksum mode in order to strengthen the decapsulator's check of 404 the IPv6 source address (i.e the same IPv6 source address is not 405 to be used with more than one IPv6 destination address, 406 irrespective of whether that destination address is a unicast or 407 multicast address). When this is not possible, it is RECOMMENDED 408 to use each source address for as few LISP-GPE tunnels that use 409 zero UDP checksum as is feasible 411 5. Measures SHOULD be taken to prevent LISP-GPE traffic over IPv6 412 with zero UDP checksum from escaping into the general Internet. 413 Examples of such measures include employing packet filters at the 414 PETR and/or keeping logical or physical separation of LISP 415 network from networks carrying General Internet 417 The above requirements do not change either the requirements 418 specified in [RFC2460] as modified by [RFC6935] or the requirements 419 specified in [RFC6936]. 421 The requirement to check the source IPv6 address in addition to the 422 destination IPv6 address, plus the recommendation against reuse of 423 source IPv6 addresses among LISP-GPE tunnels collectively provide 424 some mitigation for the absence of UDP checksum coverage of the IPv6 425 header. A traffic-managed controlled environment that satisfies at 426 least one of three conditions listed at the beginning of this section 427 provides additional assurance. 429 4.4. DSCP, ECN, TTL, and 802.1Q 431 When encapsulating IP (including over Ethernet) packets [RFC2983] 432 provides guidance for mapping DSCP between inner and outer IP 433 headers. The Pipe model typically fits better Network 434 virtualization. The DSCP value on the tunnel header is set based on 435 a policy (which may be a fixed value, one based on the inner traffic 436 class, or some other mechanism for grouping traffic). Some aspects 437 of the Uniform model (which treats the inner and outer DSCP value as 438 a single field by copying on ingress and egress) may also apply, such 439 as the ability to remark the inner header on tunnel egress based on 440 transit marking. However, the Uniform model is not conceptually 441 consistent with network virtualization, which seeks to provide strong 442 isolation between encapsulated traffic and the physical network. 444 [RFC6040] describes the mechanism for exposing ECN capabilities on IP 445 tunnels and propagating congestion markers to the inner packets. 446 This behavior MUST be followed for IP packets encapsulated in LISP- 447 GPE. 449 Though Uniform or Pipe models could be used for TTL (or Hop Limit in 450 case of IPv6) handling when tunneling IP packets, Pipe model is more 451 aligned with network virtualization. [RFC2003] provides guidance on 452 handling TTL between inner IP header and outer IP tunnels; this model 453 is more aligned with the Pipe model and is recommended for use with 454 LISP-GPE for network virtualization applications. 456 When a LISP-GPE router performs Ethernet encapsulation, the inner 457 802.1Q [IEEE.802.1Q_2014] 3-bit priority code point (PCP) field MAY 458 be mapped from the encapsulated frame to the DSCP codepoint of the DS 459 field defined in [RFC2474]. 461 When a LISP-GPE router performs Ethernet encapsulation, the inner 462 header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped 463 to, or used to determine the LISP Instance IDentifier (IID) field. 465 5. Backward Compatibility 467 LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 469 When encapsulating IP packets to a non LISP-GPE capable router the 470 P-bit MUST be set to 0. That is, the encapsulation format defined in 471 this document MUST NOT be sent to a router that has not indicated 472 that it supports this specification because such a router would 473 ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so 474 would misinterpret the other LISP header fields possibly causing 475 significant errors. 477 5.1. Detection of ETR Capabilities 479 The discovery of xTR capabilities to support LISP-GPE is out of the 480 scope of this document. Given that the applicability domain of LISP- 481 GPE is a traffic-managed controlled environment, ITR/ETR (xTR) 482 configuration mechanisms may be used for this purpose. 484 6. IANA Considerations 486 6.1. LISP-GPE Next Protocol Registry 488 IANA is requested to set up a registry of LISP-GPE "Next Protocol". 489 These are 8-bit values. Next Protocol values in the table below are 490 defined in this document. New values are assigned under the 491 Specification Required policy [RFC8126]. The protocols that are 492 being assigned values do not themselves need to be IETF standards 493 track protocols. 495 +--------------+-------------------------------------+--------------+ 496 | Next | Description | Reference | 497 | Protocol | | | 498 +--------------+-------------------------------------+--------------+ 499 | 0x0 | Reserved | This | 500 | | | Document | 501 | 0x1 | IPv4 | This | 502 | | | Document | 503 | 0x2 | IPv6 | This | 504 | | | Document | 505 | 0x3 | Ethernet | This | 506 | | | Document | 507 | 0x4 | NSH | This | 508 | | | Document | 509 | 0x05..0x7D | Unassigned | | 510 | 0x7E..0x7F | Experimentation and testing | This | 511 | | | Document | 512 | 0x80..0xFD | Unassigned (shim headers) | | 513 | 0x8E..0x8F | Experimentation and testing (shim | This | 514 | | headers) | Document | 515 +--------------+-------------------------------------+--------------+ 517 7. Security Considerations 519 LISP-GPE security considerations are similar to the LISP security 520 considerations and mitigation techniques documented in [RFC7835]. 522 LISP-GPE, as many encapsulations that use optional extensions, is 523 subject to on-path adversaries that by manipulating the P-Bit and the 524 packet itself can remove part of the payload or claim to encapsulate 525 any protocol payload type. Typical integrity protection mechanisms 526 (such as IPsec) SHOULD be used in combination with LISP-GPE by those 527 protocol extensions that want to protect from on-path attackers. 529 With LISP-GPE, issues such as data-plane spoofing, flooding, and 530 traffic redirection may depend on the particular protocol payload 531 encapsulated. 533 8. Acknowledgements and Contributors 535 A special thank you goes to Dino Farinacci for his guidance and 536 detailed review. Thanks to Tom Herbert for the suggestion to assign 537 codepoints for experimentations and testing. 539 This Working Group (WG) document originated as draft-lewis-lisp-gpe; 540 the following are its coauthors and contributors along with their 541 respective affiliations at the time of WG adoption. The editor of 542 this document would like to thank and recognize them and their 543 contributions. These coauthors and contributors provided invaluable 544 concepts and content for this document's creation. 546 o Darrel Lewis, Cisco Systems, Inc. 548 o Fabio Maino, Cisco Systems, Inc. 550 o Paul Quinn, Cisco Systems, Inc. 552 o Michael Smith, Cisco Systems, Inc. 554 o Navindra Yadav, Cisco Systems, Inc. 556 o Larry Kreeger 558 o Jennifer Lemon, Broadcom 560 o Puneet Agarwal, Innovium 562 9. References 564 9.1. Normative References 566 [I-D.ietf-lisp-rfc6830bis] 567 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 568 Cabellos-Aparicio, "The Locator/ID Separation Protocol 569 (LISP)", draft-ietf-lisp-rfc6830bis-32 (work in progress), 570 March 2020. 572 [IEEE.802.1Q_2014] 573 IEEE, "IEEE Standard for Local and metropolitan area 574 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 575 DOI 10.1109/ieeestd.2014.6991462, December 2014, 576 . 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, 581 DOI 10.17487/RFC2119, March 1997, 582 . 584 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 585 Notification", RFC 6040, DOI 10.17487/RFC6040, November 586 2010, . 588 9.2. Informative References 590 [I-D.brockners-ippm-ioam-vxlan-gpe] 591 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 592 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., 593 Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 594 Encapsulation for In-situ OAM Data", draft-brockners-ippm- 595 ioam-vxlan-gpe-03 (work in progress), November 2019. 597 [I-D.ietf-tsvwg-ecn-encap-guidelines] 598 Briscoe, B., Kaippallimalil, J., and P. Thaler, 599 "Guidelines for Adding Congestion Notification to 600 Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- 601 encap-guidelines-13 (work in progress), May 2019. 603 [I-D.lemon-vxlan-lisp-gpe-gbp] 604 Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group 605 Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- 606 vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. 608 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 609 DOI 10.17487/RFC2003, October 1996, 610 . 612 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 613 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 614 December 1998, . 616 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 617 "Definition of the Differentiated Services Field (DS 618 Field) in the IPv4 and IPv6 Headers", RFC 2474, 619 DOI 10.17487/RFC2474, December 1998, 620 . 622 [RFC2983] Black, D., "Differentiated Services and Tunnels", 623 RFC 2983, DOI 10.17487/RFC2983, October 2000, 624 . 626 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 627 Considered Useful", BCP 82, RFC 3692, 628 DOI 10.17487/RFC3692, January 2004, 629 . 631 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 632 UDP Checksums for Tunneled Packets", RFC 6935, 633 DOI 10.17487/RFC6935, April 2013, 634 . 636 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 637 for the Use of IPv6 UDP Datagrams with Zero Checksums", 638 RFC 6936, DOI 10.17487/RFC6936, April 2013, 639 . 641 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 642 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 643 eXtensible Local Area Network (VXLAN): A Framework for 644 Overlaying Virtualized Layer 2 Networks over Layer 3 645 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 646 . 648 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 649 Separation Protocol (LISP) Threat Analysis", RFC 7835, 650 DOI 10.17487/RFC7835, April 2016, 651 . 653 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 654 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 655 March 2017, . 657 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 658 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 659 March 2017, . 661 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 662 Writing an IANA Considerations Section in RFCs", BCP 26, 663 RFC 8126, DOI 10.17487/RFC8126, June 2017, 664 . 666 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 667 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 668 May 2017, . 670 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 671 "Network Service Header (NSH)", RFC 8300, 672 DOI 10.17487/RFC8300, January 2018, 673 . 675 Authors' Addresses 677 Fabio Maino (editor) 678 Cisco Systems 679 San Jose, CA 95134 680 USA 682 Email: fmaino@cisco.com 684 Jennifer Lemon 685 Broadcom 686 270 Innovation Drive 687 San Jose, CA 95134 688 USA 690 Email: jennifer.lemon@broadcom.com 692 Puneet Agarwal 693 Innovium 694 USA 696 Email: puneet@acm.org 697 Darrel Lewis 698 Cisco Systems 699 San Jose, CA 95134 700 USA 702 Email: darlewis@cisco.com 704 Michael Smith 705 Cisco Systems 706 San Jose, CA 95134 707 USA 709 Email: michsmit@cisco.com