idnits 2.17.1 draft-ietf-nvo3-vxlan-gpe-10.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 1354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-vxlan-gpe-03 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Maino, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Kreeger, Ed. 5 Expires: January 14, 2021 Arrcus 6 U. Elzur, Ed. 7 Intel 8 July 13, 2020 10 Generic Protocol Extension for VXLAN (VXLAN-GPE) 11 draft-ietf-nvo3-vxlan-gpe-10 13 Abstract 15 This document describes extending Virtual eXtensible Local Area 16 Network (VXLAN), via changes to the VXLAN header, with four new 17 capabilities: support for multi-protocol encapsulation, support for 18 operations, administration and maintenance (OAM) signaling, support 19 for ingress-replicated BUM Traffic (i.e. Broadcast, Unknown unicast, 20 or Multicast), and explicit versioning. New protocol capabilities 21 can be introduced via shim headers. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 14, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. VXLAN Without Protocol Extension . . . . . . . . . . . . . . 3 65 3. Generic Protocol Extension for VXLAN (VXLAN-GPE) . . . . . . 4 66 3.1. VXLAN-GPE Header . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Multi Protocol Support . . . . . . . . . . . . . . . . . 5 68 3.3. Replicated BUM Traffic . . . . . . . . . . . . . . . . . 7 69 3.4. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.5. Version Bits . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Outer Encapsulations . . . . . . . . . . . . . . . . . . . . 8 72 4.1. Inner VLAN Tag Handling . . . . . . . . . . . . . . . . . 11 73 4.2. Fragmentation Considerations . . . . . . . . . . . . . . 12 74 5. Implementation and Deployment Considerations . . . . . . . . 12 75 5.1. Applicability Statement . . . . . . . . . . . . . . . . . 12 76 5.2. Congestion Control Functionality . . . . . . . . . . . . 13 77 5.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 13 78 5.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 13 79 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 80 6.1. VXLAN VTEP to VXLAN-GPE VTEP . . . . . . . . . . . . . . 15 81 6.2. VXLAN-GPE VTEP to VXLAN VTEP . . . . . . . . . . . . . . 15 82 6.3. VXLAN-GPE UDP Ports . . . . . . . . . . . . . . . . . . . 15 83 6.4. VXLAN-GPE and Encapsulated IP Header Fields . . . . . . . 15 84 7. VXLAN-GPE Examples . . . . . . . . . . . . . . . . . . . . . 16 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 11.1. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 19 90 11.2. VXLAN-GPE Next Protocol . . . . . . . . . . . . . . . . 19 91 11.3. VXLAN-GPE Flag and Reserved Bits . . . . . . . . . . . . 19 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 12.2. Informative References . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 Virtual eXtensible Local Area Network VXLAN [RFC7348] defines an 100 encapsulation format that encapsulates Ethernet frames in an outer 101 UDP/IP transport. As data centers evolve, the need to carry other 102 protocols encapsulated in an IP packet is required, as well as the 103 need to provide increased visibility and diagnostic capabilities 104 within the overlay. The VXLAN header does not specify the protocol 105 being encapsulated and therefore is currently limited to 106 encapsulating only Ethernet frame payload, nor does it provide the 107 ability to define OAM protocols. In addition, [RFC6335] requires 108 that new transports not use transport layer port numbers to identify 109 tunnel payload, rather it encourages encapsulations to use their own 110 identifiers for this purpose. VXLAN-GPE is intended to extend the 111 existing VXLAN protocol to provide protocol typing, OAM, and 112 versioning capabilities. 114 The Version and OAM bits are introduced in Section 3, and the choice 115 of location for these fields is driven by minimizing the impact on 116 existing deployed hardware. 118 In order to facilitate deployments of VXLAN-GPE with hardware 119 currently deployed to support VXLAN, changes from legacy VXLAN have 120 been kept to a minimum. Section 6 provides a detailed discussion 121 about how VXLAN-GPE addresses the requirement for backward 122 compatibility with VXLAN. 124 The capabilities of the VXLAN-GPE protocol can be extended by 125 defining next protocol "shim" headers that are used to implement new 126 data plane functions. For example, Group-Based Policy (GBP) or In- 127 situ Operations, Administration, and Maintenance (IOAM) metadata 128 functionalities can be added as specified in 129 [I-D.lemon-vxlan-lisp-gpe-gbp] and 130 [I-D.brockners-ippm-ioam-vxlan-gpe]. 132 2. VXLAN Without Protocol Extension 134 VXLAN provides a method of creating multi-tenant overlay networks by 135 encapsulating packets in IP/UDP along with a header containing a 136 network identifier which is used to isolate tenant traffic in each 137 overlay network from each other. This allows the overlay networks to 138 run over an existing IP network. 140 Through this encapsulation, VXLAN creates stateless tunnels between 141 VXLAN Tunnel End Points (VTEPs) which are responsible for adding/ 142 removing the IP/UDP/VXLAN headers and providing tenant traffic 143 isolation based on the VXLAN Network Identifier (VNI). Tenant 144 systems are unaware that their networking service is being provided 145 by an overlay. 147 When encapsulating packets, a VTEP must know the IP address of the 148 proper remote VTEP at the far end of the tunnel that can deliver the 149 inner packet to the Tenant System corresponding to the inner 150 destination address. The control plane used to distribute inner to 151 outer mappings is out of the scope of this document. 153 The VXLAN Network Identifier (VNI) provides scoping for the addresses 154 in the header of the encapsulated PDU. If the encapsulated packet is 155 an Ethernet frame, this means the Ethernet MAC addresses are only 156 unique within a given VNI and may overlap with MAC addresses within a 157 different VNI. If the encapsulated packet is an IP packet, this 158 means the IP addresses are only unique within that VNI. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 |R|R|R|R|I|R|R|R| Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | VXLAN Network Identifier (VNI) | Reserved | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 1: VXLAN Header 170 3. Generic Protocol Extension for VXLAN (VXLAN-GPE) 172 3.1. VXLAN-GPE Header 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |R|R|Ver|I|P|B|O| Reserved |Next Protocol | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | VXLAN Network Identifier (VNI) | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: VXLAN-GPE Header 184 Flags (8 bits): The first 8 bits of the header are the flag field. 185 The bits designated "R" above are reserved flags. These MUST be 186 set to zero on transmission and ignored on receipt. 188 Version (Ver): Indicates VXLAN-GPE protocol version. The initial 189 version is 0. If a receiver does not support the version 190 indicated it MUST drop the packet. 192 Instance Bit (I bit): The I bit MUST be set to indicate a valid VNI. 194 Next Protocol Bit (P bit): The P bit is set to indicate that the 195 Next Protocol field is present. 197 BUM Traffic Bit (B bit): The B bit is set to indicate that this is 198 ingress-replicated BUM Traffic (ie, Broadcast, Unknown unicast, or 199 Multicast). 201 OAM Flag Bit (O bit): The O bit is set to indicate that the packet 202 is an OAM packet. 204 Next Protocol: This 8 bit field indicates the protocol header 205 immediately following the VXLAN-GPE header. 207 VNI: This 24 bit field identifies the VXLAN overlay network the 208 inner packet belongs to. Inner packets belonging to different 209 VNIs cannot communicate with each other (unless explicitly allowed 210 by policy). 212 Reserved: Reserved fields MUST be set to zero on transmission and 213 ignored on receipt. 215 3.2. Multi Protocol Support 217 This draft defines the following two changes to the VXLAN header in 218 order to support multi-protocol encapsulation: 220 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 221 MUST be set to 1 to indicate the presence of the 8 bit next 222 protocol field. 224 When UDP dest port=4790, P = 0 the "Next Protocol" field must be 225 set to zero and the payload MUST be ETHERNET(L2) as defined by 226 [RFC7348]. 228 Flag bit 5 was chosen as the P bit because this flag bit is 229 currently reserved in VXLAN. 231 Next Protocol Field: The lower 8 bits of the first word are used to 232 carry a next protocol. This next protocol field contains the 233 protocol of the encapsulated payload packet. A new protocol 234 registry will be requested from IANA, see section 10.2. 236 This draft defines the following Next Protocol values: 238 0x00 : Reserved 240 0x01 : IPv4 242 0x02 : IPv6 244 0x03 : Ethernet 246 0x04 : Network Service Header [RFC8300] 248 0x05 to 0x7D: Unassigned 250 0x7E, 0x7F: Experimentation and testing 252 0x80 to 0xFD: Unassigned (shim headers) 254 0xFE, 0xFF: Experimentation and testing (shim headers) 256 Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for 257 experimentation and testing as per [RFC3692]. 259 Next protocol values from Ox80 to 0xFD are assigned to protocols 260 encoded as generic "shim" headers. All shim protocols MUST use the 261 header structure in Figure 3, which includes a Type, a Lenght, and a 262 Next Protocol field. When shim headers are used with other protocols 263 identified by next protocol values from 0x0 to 0x7F, all the shim 264 headers MUST come first. 266 Shim headers can be used to incrementally deploy new GPE features 267 without updating the implementation of each transit node between two 268 tunnel endpoints, and without punting the packet with shim headers of 269 unknown type to the 'slow' path. Transit nodes that are not aware of 270 a given shim header type MUST ignore that shim header and proceed to 271 parse the next protocol. 273 VTEP implementations can keep the processing of known shim headers in 274 the 'fast' path (typically an ASIC), while punting the processing of 275 the remaining new GPE features to the 'slow' path. 277 Shim protocols MUST have the first 32 bits defined as: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Length | Reserved | Next Protocol | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 ~ Protocol Specific Fields ~ 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3: Shim Header 291 Where: 293 Type: This field MAY be used to identify different messages of this 294 protocol. 296 Length: The length, in in 4-octet units, of this protocol message 297 not including the first 4 octets. 299 Reserved: The use of this field is reserved to the protocol defined 300 in this message. 302 Next Protocol Field: This next protocol field contains the protocol 303 of the encapsulated payload. The protocol registry will be 304 requested from IANA as per section 10.2. 306 3.3. Replicated BUM Traffic 308 Flag bit 6 is defined as the B bit. When the B bit is set to 1, the 309 packet is marked as an an ingress-replicated BUM Traffic (i.e. 310 Broadcast, Unknown unicast, or Multicast) to help egress VTEP to 311 differentiate between known and unknown unicast. The details of 312 using the B bit are out of scope for this document, but please see 313 [RFC8365] for an example in the EVPN context. As with the P-bit, bit 314 6 is currently a reserved flag in VXLAN. 316 3.4. OAM Support 318 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 319 packet is an OAM packet and OAM processing MUST occur. Other header 320 fields including Next Protocol MUST adhere to the definitions in 321 Section 3. The OAM protocol details are out of scope for this 322 document. As with the P-bit, bit 7 is currently a reserved flag in 323 VXLAN. 325 3.5. Version Bits 327 VXLAN-GPE bits 2 and 3 are defined as version bits. These bits are 328 reserved in VXLAN. The version field is used to ensure backward 329 compatibility going forward with future VXLAN-GPE updates. 331 The initial version for VXLAN-GPE is 0. 333 4. Outer Encapsulations 335 In addition to the VXLAN-GPE header, the packet is further 336 encapsulated in UDP and IP. Data centers based on Ethernet, will 337 then send this IP packet over Ethernet. 339 Outer UDP Header: 341 Destination UDP Port: IANA has assigned the value 4790 for the VXLAN- 342 GPE UDP port. This well-known destination port is used when sending 343 VXLAN-GPE encapsulated packets. 345 Source UDP Port: The source UDP port is used as entropy for devices 346 forwarding encapsulated packets across the underlay (ECMP for IP 347 routers, or load splitting for link aggregation by bridges). Tenant 348 traffic flows should all use the same source UDP port to lower the 349 chances of packet reordering by the underlay for a given flow. It is 350 recommended for VTEPs to generate this port number using a hash of 351 the inner packet headers. Implementations MAY use the entire 16 bit 352 source UDP port for entropy. 354 UDP Checksum: see Section 5.3 for considerations related to UDP 355 Checksum processing. 357 Outer IP Header: 359 This is the header used by the underlay network to deliver packets 360 between VTEPs. The destination IP address can be a unicast or a 361 multicast IP address. The source IP address must be the source VTEP 362 IP address which can be used to return tenant packets to the tenant 363 system source address within the inner packet header. 365 When the outer IP header is IPv4, VTEPs MUST set the DF bit. 367 Outer Ethernet Header: 369 Most data centers networks are built on Ethernet. Assuming the outer 370 IP packet is being sent across Ethernet, there will be an Ethernet 371 header used to deliver the IP packet to the next hop, which could be 372 the destination VTEP or be a router used to forward the IP packet 373 towards the destination VTEP. If VLANs are in use within the data 374 center, then this Ethernet header would also contain a VLAN tag. 376 The following figures show the entire stack of protocol headers that 377 would be seen on an Ethernet link carrying encapsulated packets from 378 a VTEP across the underlay network for both IPv4 and IPv6 based 379 underlay networks. 381 0 1 2 3 382 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 384 Outer Ethernet Header: 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Outer Destination MAC Address | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Outer Destination MAC Address | Outer Source MAC Address | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Outer Source MAC Address | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Ethertype = 0x0800 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Outer IPv4 Header: 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |Version| IHL |Type of Service| Total Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Identification |Flags| Fragment Offset | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Time to Live |Protocl=17(UDP)| Header Checksum | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Outer Source IPv4 Address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Outer Destination IPv4 Address | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Outer UDP Header: 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Source Port | Dest Port = 4790 | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | UDP Length | UDP Checksum | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 VXLAN-GPE Header: 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | VXLAN Network Identifier (VNI) | Reserved | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Payload: 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Depends on VXLAN-GPE Next Protocol field above. | 428 | Note that if the payload is Ethernet, then the original | 429 | Ethernet Frame's FCS is not included. | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Frame Check Sequence: 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 4: Outer Headers for VXLAN-GPE over IPv4 439 0 1 2 3 440 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 442 Outer Ethernet Header: 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Outer Destination MAC Address | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Outer Destination MAC Address | Outer Source MAC Address | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Outer Source MAC Address | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Ethertype = 0x86DD | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Outer IPv6 Header: 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |Version| Traffic Class | Flow Label | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 + + 463 | | 464 + Outer Source IPv6 Address + 465 | | 466 + + 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 + + 471 | | 472 + Outer Destination IPv6 Address + 473 | | 474 + + 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Outer UDP Header: 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Source Port | Dest Port = 4790 | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | UDP Length | UDP Checksum | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 VXLAN-GPE Header: 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | VXLAN Network Identifier (VNI) | Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Payload: 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Depends on VXLAN-GPE Next Protocol field above. | 495 | Note that if the payload is Ethernet, then the original | 496 | Ethernet Frame's FCS is not included. | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Frame Check Sequence: 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 5: Outer Headers for VXLAN-GPE over IPv6 506 4.1. Inner VLAN Tag Handling 508 If the inner packet (as indicated by the VXLAN-GPE Next Protocol 509 field) is an Ethernet frame, it is recommended that it does not 510 contain a VLAN tag. In the most common scenarios, the tenant VLAN 511 tag is translated into a VXLAN Network Identifier. In these 512 scenarios, VTEPs should never send an inner Ethernet frame with a 513 VLAN tag, and a VTEP performing decapsulation should discard any 514 inner frames received with a VLAN tag. However, if the VTEPs are 515 specifically configured to support it for a specific VXLAN Network 516 Identifier, a VTEP may support transparent transport of the inner 517 VLAN tag between all tenant systems on that VNI. The VTEP never 518 looks at the value of the inner VLAN tag, but simply passes it across 519 the underlay. 521 4.2. Fragmentation Considerations 523 VTEPs MUST never fragment an encapsulated VXLAN-GPE packet, and when 524 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer 525 IPv4 header. It is recommended that the underlay network be 526 configured to carry an MTU at least large enough to accommodate the 527 added encapsulation headers. It is recommended that VTEPs perform 528 Path MTU discovery [RFC1191] [RFC1981] to determine if the underlay 529 network can carry the encapsulated payload packet. 531 5. Implementation and Deployment Considerations 533 5.1. Applicability Statement 535 VXLAN-GPE conforms, as an UDP-based encapsulation protocol, to the 536 UDP usage guidelines as specified in [RFC8085]. The applicability of 537 these guidelines are dependent on the underlay IP network and the 538 nature of the encapsulated payload. 540 [RFC8085] outlines two applicability scenarios for UDP applications, 541 1) general Internet and 2) controlled environment. The controlled 542 environment means a single administrative domain or adjacent set of 543 cooperating domains. A network in a controlled environment can be 544 managed to operate under certain conditions whereas in general 545 Internet this cannot be done. Hence requirements for a tunnel 546 protocol operating under a controlled environment can be less 547 restrictive than the requirements of general internet. 549 VXLAN-GPE is intended to be deployed in a data center network 550 environment operated by a single operator or adjacent set of 551 cooperating network operators that fits with the definition of 552 controlled environments in [RFC8085]. 554 For the purpose of this document, a traffic-managed controlled 555 environment (TMCE), outlined in [RFC8086], is defined as an IP 556 network that is traffic-engineered and/or otherwise managed (e.g., 557 via use of traffic rate limiters) to avoid congestion. Significant 558 portions of text in this Section are based on [RFC8086]. 560 It is the responsibility of the network operators to ensure that the 561 guidelines/requirements in this section are followed as applicable to 562 their VXLAN-GPE deployments 564 5.2. Congestion Control Functionality 566 VXLAN-GPE does not natively provide congestion control functionality 567 and relies on the payload protocol traffic for congestion control. 568 As such VXLAN-GPE MUST be used with congestion controlled traffic or 569 within a network that is traffic managed to avoid congestion (TMCE). 570 An operator of a traffic managed network (TMCE) may avoid congestion 571 by careful provisioning of their networks, rate-limiting of user data 572 traffic and traffic engineering according to path capacity. 574 5.3. UDP Checksum 576 In order to provide integrity of VXLAN-GPE headers and payload, for 577 example to avoid mis-delivery of payload to different tenant systems 578 in case of data corruption, outer UDP checksum SHOULD be used with 579 VXLAN-GPE when transported over IPv4. The UDP checksum provides a 580 statistical guarantee that a payload was not corrupted in transit. 581 These integrity checks are not strong from a coding or cryptographic 582 perspective and are not designed to detect physical-layer errors or 583 malicious modification of the datagram (see Section 3.4 of 584 [RFC8085]). In deployments where such a risk exists, an operator 585 SHOULD use additional data integrity mechanisms such as offered by 586 IPSec. 588 An operator MAY choose to disable UDP checksum and use zero checksum 589 if VXLAN-GPE packet integrity is provided by other data integrity 590 mechanisms such as IPsec or additional checksums or if one of the 591 conditions in Section 5.3.1 a, b, c are met. 593 5.3.1. UDP Zero Checksum Handling with IPv6 595 By default, UDP checksum MUST be used when VXLAN-GPE is transported 596 over IPv6. A tunnel endpoint MAY be configured for use with zero UDP 597 checksum if additional requirements described in this section are 598 met. 600 When VXLAN-GPE is used over IPv6, UDP checksum is used to protect 601 IPv6 headers, UDP headers and VXLAN-GPE headers and payload from 602 potential data corruption. As such by default VXLAN-GPE MUST use UDP 603 checksum when transported over IPv6. An operator MAY choose to 604 configure to operate with zero UDP checksum if operating in a traffic 605 managed controlled environment as stated in Section 5.1 if one of the 606 following conditions are met: 608 a. It is known that the packet corruption is exceptionally unlikely 609 (perhaps based on knowledge of equipment types in their underlay 610 network) and the operator is willing to take a risk of undetected 611 packet corruption 613 b. It is judged through observational measurements (perhaps through 614 historic or current traffic flows that use non zero checksum) 615 that the level of packet corruption is tolerably low and where 616 the operator is willing to take the risk of undetected corruption 618 c. VXLAN-GPE payload is carrying applications that are tolerant of 619 misdelivered or corrupted packets (perhaps through higher layer 620 checksum validation and/or reliability through retransmission) 622 In addition VXLAN-GPE tunnel implementations using Zero UDP checksum 623 MUST meet the following requirements: 625 1. Use of UDP checksum over IPv6 MUST be the default configuration 626 for all VXLAN-GPE tunnels 628 2. If VXLAN-GPE is used with zero UDP checksum over IPv6 then such 629 VTEP implementation MUST meet all the requirements specified in 630 section 4 of [RFC6936] and requirements 1 as specified in section 631 5 of [RFC6936] 633 3. The VTEP that decapsulates the packet SHOULD check the source and 634 destination IPv6 addresses are valid for the VXLAN-GPE tunnel 635 that is configured to receive Zero UDP checksum and discard other 636 packets for which such check fails 638 4. The VTEP that encapsulates the packet MAY use different IPv6 639 source addresses for each VXLAN-GPE tunnel that uses Zero UDP 640 checksum mode in order to strengthen the decapsulator's check of 641 the IPv6 source address (i.e the same IPv6 source address is not 642 to be used with more than one IPv6 destination address, 643 irrespective of whether that destination address is a unicast or 644 multicast address). When this is not possible, it is RECOMMENDED 645 to use each source address for as few VXLAN-GPE tunnels that use 646 zero UDP checksum as is feasible 648 5. Measures SHOULD be taken to prevent VXLAN-GPE traffic over IPv6 649 with zero UDP checksum from escaping into the general Internet. 650 Examples of such measures include employing packet filters at the 651 gateways or edge of a VXLAN-GPE network, and/or keeping logical 652 or physical separation of VXLAN network from networks carrying 653 General Internet 655 The above requirements do not change either the requirements 656 specified in [RFC2460] as modified by [RFC6935] or the requirements 657 specified in [RFC6936]. 659 The requirement to check the source IPv6 address in addition to the 660 destination IPv6 address, plus the recommendation against reuse of 661 source IPv6 addresses among VXLAN-GPE tunnels collectively provide 662 some mitigation for the absence of UDP checksum coverage of the IPv6 663 header. A traffic-managed controlled environment that satisfies at 664 least one of three conditions listed at the beginning of this section 665 provides additional assurance. 667 6. Backward Compatibility 669 6.1. VXLAN VTEP to VXLAN-GPE VTEP 671 A VXLAN VTEP conforms to VXLAN frame format and uses UDP destination 672 port 4789 when sending traffic to VXLAN-GPE VTEP. As per VXLAN, 673 reserved bits 5 and 7, VXLAN-GPE P and O-bits respectively must be 674 set to zero. The remaining reserved bits must be zero, including the 675 VXLAN-GPE version field, bits 2 and 3. The encapsulated payload MUST 676 be Ethernet. 678 6.2. VXLAN-GPE VTEP to VXLAN VTEP 680 A VXLAN-GPE VTEP MUST NOT encapsulate non-Ethernet frames to a VXLAN 681 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN- 682 GPE VTEP MUST conform to VXLAN frame format and hence will set the P 683 bit to 0, the Next Protocol to 0 and use UDP destination port 4789. 684 A VXLAN-GPE VTEP MUST also set O = 0 and Ver = 0 when encapsulating 685 Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP will treat 686 this packet as a VXLAN packet. 688 A method for determining the capabilities of a VXLAN VTEP (GPE or 689 non-GPE) is out of the scope of this draft. 691 6.3. VXLAN-GPE UDP Ports 693 VXLAN-GPE uses a IANA assigned UDP destination port, 4790, when 694 sending traffic to VXLAN-GPE VTEPs. 696 6.4. VXLAN-GPE and Encapsulated IP Header Fields 698 When encapsulating IP (including over Ethernet) packets [RFC2983] 699 provides guidance for mapping DSCP between inner and outer IP 700 headers. The Pipe model typically fits better Network 701 virtualization. The DSCP value on the tunnel header is set based on 702 a policy (which may be a fixed value, one based on the inner traffic 703 class, or some other mechanism for grouping traffic). Some aspects 704 of the Uniform model (which treats the inner and outer DSCP value as 705 a single field by copying on ingress and egress) may also apply, such 706 as the ability to remark the inner header on tunnel egress based on 707 transit marking. However, the Uniform model is not conceptually 708 consistent with network virtualization, which seeks to provide strong 709 isolation between encapsulated traffic and the physical network. 711 [RFC6040] describes the mechanism for exposing ECN capabilities on IP 712 tunnels and propagating congestion markers to the inner packets. 713 This behavior MUST be followed for IP packets encapsulated in VXLAN- 714 GPE. 716 Though Uniform or Pipe models could be used for TTL (or Hop Limit in 717 case of IPv6) handling when tunneling IP packets, Pipe model is more 718 aligned with network virtualization. [RFC2003] provides guidance on 719 handling TTL between inner IP header and outer IP tunnels; this model 720 is more aligned with the Pipe model and is recommended for use with 721 VXLAN-GPE for network virtualization applications. 723 When a VXLAN-GPE router performs Ethernet encapsulation, the inner 724 802.1Q 3-bit priority code point (PCP) field MAY be mapped from the 725 encapsulated frame to the DSCP codepoint of the DS field defined in 726 [RFC2474]. 728 When a VXLAN-GPE router performs Ethernet encapsulation, the inner 729 header 802.1Q VLAN Identifier (VID) MAY be mapped to, or used to 730 determine the VXLAN Network Identitifer (VNI) field. 732 7. VXLAN-GPE Examples 734 This section provides three examples of protocols encapsulated using 735 the Generic Protocol Extension for VXLAN described in this document. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 |R|R|0|0|I|1|R|0| Reserved | NP = IPv4 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | VXLAN Network Identifier (VNI) | Reserved | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Original IPv4 Packet | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 Figure 6: IPv4 and VXLAN-GPE 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |R|R|0|0|I|1|R|0| Reserved | NP = IPv6 | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | VXLAN Network Identifier (VNI) | Reserved | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Original IPv6 Packet | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Figure 7: IPv6 and VXLAN-GPE 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 |R|R|0|0|I|1|R|0| Reserved |NP = Ethernet | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | VXLAN Network Identifier (VNI) | Reserved | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Original Ethernet Frame | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Figure 8: Ethernet and VXLAN-GPE 773 8. Security Considerations 775 VXLAN-GPE encapsulation does not affect security for the payload 776 protocol. The security considerations for VXLAN applies to VXLAN- 777 GPE, see [RFC7348]. 779 When crossing an untrusted link, such as the public Internet, IPsec 780 [RFC4301] may be used to provide authentication and/or encryption of 781 the IP packets formed as part of VXLAN-GPE encapsulation. 783 Operators have to make an assessment based on their network 784 environment and determine the risks that are applicable to their 785 specific environment and use appropriate mitigation approaches as 786 applicable. 788 9. Contributors 789 Paul Quinn 790 Cisco Systems 791 paulq@cisco.com 793 Rajeev Manur 794 Broadcom 795 rmanur@broadcom.com 797 Michael Smith 798 Cisco Systems 799 michsmit@cisco.com 801 Darrel Lewis 802 Cisco Systems 803 darlewis@cisco.com 805 Puneet Agarwal 806 Innovium, Inc 807 puneet@acm.org 809 Lucy Yong 810 Huawei USA 811 lucy.yong@huawei.com 813 Xiaohu Xu 814 Alibaba Inc 815 xiaohu.xxh@alibaba-inc.com 817 Pankaj Garg 818 Microsoft 819 pankajg@microsoft.com 821 David Melman 822 Marvell 823 davidme@marvell.com 825 Jennifer Lemon 826 Broadcom Limited 827 jennifer.lemon@broadcom.com 829 10. Acknowledgments 831 A special thank you goes to Dino Farinacci for his guidance and 832 detailed review. Thanks to Tom Herbert for the suggestion to assign 833 codepoints for experimentations and testing. 835 11. IANA Considerations 837 11.1. UDP Port 839 UDP 4790 port has been assigned by IANA for VXLAN-GPE. 841 11.2. VXLAN-GPE Next Protocol 843 IANA is requested to set up a registry of "Next Protocol". These are 844 8-bit values. Next Protocol values in the table below are defined in 845 this draft. New values are assigned via Standards Action [RFC5226]. 847 +--------------+-------------------------------------+--------------+ 848 | Next | Description | Reference | 849 | Protocol | | | 850 +--------------+-------------------------------------+--------------+ 851 | 0x0 | Reserved | This | 852 | | | Document | 853 | 0x1 | IPv4 | This | 854 | | | Document | 855 | 0x2 | IPv6 | This | 856 | | | Document | 857 | 0x3 | Ethernet | This | 858 | | | Document | 859 | 0x4 | NSH | This | 860 | | | Document | 861 | 0x05..0x7D | Unassigned | | 862 | 0x7E, 0x7F | Experimentation and testing | This | 863 | | | Document | 864 | 0x80..0xFD | Unassigned (shim headers) | | 865 | 0x8E, 0x8F | Experimentation and testing (shim | This | 866 | | headers) | Document | 867 +--------------+-------------------------------------+--------------+ 869 11.3. VXLAN-GPE Flag and Reserved Bits 871 There are ten flag bits at the beginning of the VXLAN-GPE header, 872 followed by 16 reserved bits and an 8-bit reserved field at the end 873 of the header. New bits are assigned via Standards Action [RFC5226]. 875 Bits 0-1 - Reserve6 877 Bits 2-3 - Version 879 Bit 4 - Instance ID (I bit) 881 Bit 5 - Next Protocol (P bit) 882 Bit 6 - Reserved 884 Bit 7 - OAM (O bit) 886 Bit 8-23 - Reserved 888 Bits 24-31 in the 2nd Word -- Reserved 890 Reserved bits/fields MUST be set to 0 by the sender and ignored by 891 the receiver. 893 12. References 895 12.1. Normative References 897 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 898 DOI 10.17487/RFC1191, November 1990, 899 . 901 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 902 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 903 1996, . 905 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 906 DOI 10.17487/RFC2003, October 1996, 907 . 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, 911 DOI 10.17487/RFC2119, March 1997, 912 . 914 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 915 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 916 December 1998, . 918 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 919 "Definition of the Differentiated Services Field (DS 920 Field) in the IPv4 and IPv6 Headers", RFC 2474, 921 DOI 10.17487/RFC2474, December 1998, 922 . 924 [RFC2983] Black, D., "Differentiated Services and Tunnels", 925 RFC 2983, DOI 10.17487/RFC2983, October 2000, 926 . 928 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 929 Considered Useful", BCP 82, RFC 3692, 930 DOI 10.17487/RFC3692, January 2004, 931 . 933 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 934 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 935 December 2005, . 937 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 938 IANA Considerations Section in RFCs", RFC 5226, 939 DOI 10.17487/RFC5226, May 2008, 940 . 942 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 943 Notification", RFC 6040, DOI 10.17487/RFC6040, November 944 2010, . 946 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 947 Cheshire, "Internet Assigned Numbers Authority (IANA) 948 Procedures for the Management of the Service Name and 949 Transport Protocol Port Number Registry", BCP 165, 950 RFC 6335, DOI 10.17487/RFC6335, August 2011, 951 . 953 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 954 UDP Checksums for Tunneled Packets", RFC 6935, 955 DOI 10.17487/RFC6935, April 2013, 956 . 958 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 959 for the Use of IPv6 UDP Datagrams with Zero Checksums", 960 RFC 6936, DOI 10.17487/RFC6936, April 2013, 961 . 963 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 964 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 965 eXtensible Local Area Network (VXLAN): A Framework for 966 Overlaying Virtualized Layer 2 Networks over Layer 3 967 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 968 . 970 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 971 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 972 March 2017, . 974 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 975 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 976 March 2017, . 978 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 979 "Network Service Header (NSH)", RFC 8300, 980 DOI 10.17487/RFC8300, January 2018, 981 . 983 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 984 Uttaro, J., and W. Henderickx, "A Network Virtualization 985 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 986 DOI 10.17487/RFC8365, March 2018, 987 . 989 12.2. Informative References 991 [I-D.brockners-ippm-ioam-vxlan-gpe] 992 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 993 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., 994 Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE 995 Encapsulation for In-situ OAM Data", draft-brockners-ippm- 996 ioam-vxlan-gpe-03 (work in progress), November 2019. 998 [I-D.lemon-vxlan-lisp-gpe-gbp] 999 Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group 1000 Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- 1001 vxlan-lisp-gpe-gbp-02 (work in progress), April 2019. 1003 Authors' Addresses 1005 Fabio Maino (Editor) 1006 Cisco Systems 1008 Email: fmaino@cisco.com 1010 Larry Kreeger (editor) 1011 Arrcus 1013 Email: lkreeger@gmail.com 1015 Uri Elzur (editor) 1016 Intel 1018 Email: uri.elzur@intel.com