idnits 2.17.1 draft-ietf-nvo3-vxlan-gpe-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 4, 2015) is 3090 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) == Unused Reference: 'RFC0768' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 626, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track R. Manur 5 Expires: May 7, 2016 Broadcom 6 L. Kreeger 7 D. Lewis 8 F. Maino 9 M. Smith 10 Cisco Systems, Inc. 11 P. Agarwal 12 Innovium, Inc 13 L. Yong 14 Huawei USA 15 X. Xu 16 Huawei Technologies 17 U. Elzur 18 Intel 19 P. Garg 20 Microsoft 21 D. Melman 22 Marvell 23 November 4, 2015 25 Generic Protocol Extension for VXLAN 26 draft-ietf-nvo3-vxlan-gpe-01.txt 28 Abstract 30 This draft describes extending Virtual eXtensible Local Area Network 31 (VXLAN), via changes to the VXLAN header, with three new 32 capabilities: support for multi-protocol encapsulation, operations, 33 administration and management (OAM) signaling and explicit 34 versioning. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 7, 2016. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. VXLAN Without Protocol Extension . . . . . . . . . . . . . . . 5 72 3. Generic Protocol Extension for VXLAN (VXLAN GPE) . . . . . . . 7 73 3.1. VXLAN GPE Header . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Multi Protocol Support . . . . . . . . . . . . . . . . . . 8 75 3.3. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.4. Version Bits . . . . . . . . . . . . . . . . . . . . . . . 8 77 4. Outer Encapsulations . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. Inner VLAN Tag Handling . . . . . . . . . . . . . . . . . 13 79 4.2. Fragmentation Considerations . . . . . . . . . . . . . . . 13 80 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 14 81 5.1. VXLAN VTEP to VXLAN GPE VTEP . . . . . . . . . . . . . . . 14 82 5.2. VXLAN GPE VTEP to VXLAN VTEP . . . . . . . . . . . . . . . 14 83 5.3. VXLAN GPE UDP Ports . . . . . . . . . . . . . . . . . . . 14 84 5.4. VXLAN GPE and Encapsulated IP Header Fields . . . . . . . 14 85 6. VXLAN GPE Examples . . . . . . . . . . . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 9.1. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 9.2. VXLAN GPE Next Protocol . . . . . . . . . . . . . . . . . 19 91 9.3. VXLAN GPE Flag and Reserved Bits . . . . . . . . . . . . . 19 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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 5 provides a detailed discussion 121 about how VXLAN GPE addresses the requirement for backward 122 compatibility with VXLAN. 124 2. VXLAN Without Protocol Extension 126 VXLAN provides a method of creating multi-tenant overlay networks by 127 encapsulating packets in IP/UDP along with a header containing a 128 network identifier which is used to isolate tenant traffic in each 129 overlay network from each other. This allows the overlay networks to 130 run over an existing IP network. 132 Through this encapsulation, VXLAN creates stateless tunnels between 133 VXLAN Tunnel End Points (VTEPs) which are responsible for adding/ 134 removing the IP/UDP/VXLAN headers and providing tenant traffic 135 isolation based on the VXLAN Network Identifier (VNI). Tenant 136 systems are unaware that their networking service is being provided 137 by an overlay. 139 When encapsulating packets, a VTEP must know the IP address of the 140 proper remote VTEP at the far end of the tunnel that can deliver the 141 inner packet to the Tenant System corresponding to the inner 142 destination address. In the case of tenant multicast or broadcast, 143 the outer IP address may be an IP multicast group address, or the 144 VTEP may replicate the packet and send it to all known VTEPs. If 145 multicast is used in the underlay network to send encapsulated 146 packets to remote VTEPs, Any Source Multicast is used and each VTEP 147 serving a particular VNI must perform a (*, G) join to the same group 148 IP address. 150 Inner to outer address mapping can be determined in two ways. One is 151 source based learning in the data plane, and the other is 152 distribution via a control plane. 154 Source based learning requires a receiving VTEP to create an inner to 155 outer address mapping by gleaning the information from the received 156 packets by correlating the inner source address to the outer source 157 IP address. When a mapping does not exist, a VTEP forwards the 158 packets to all remote VTEPs participating in the VNI by using IP 159 multicast in the IP underlay network. Each VTEP must be configured 160 with the IP multicast address to use for each VNI. How this occurs 161 is out of scope. 163 The control plane used to distribute inner to outer mappings is also 164 out of scope. It could use a centralized authority or be 165 distributed, or use a hybrid. 167 The VXLAN Network Identifier (VNI) provides scoping for the addresses 168 in the header of the encapsulated PDU. If the encapsulated packet is 169 an Ethernet frame, this means the Ethernet MAC addresses are only 170 unique within a given VNI and may overlap with MAC addresses within a 171 different VNI. If the encapsulated packet is an IP packet, this 172 means the IP addresses are only unique within that VNI. 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|R|R|I|R|R|R| Reserved | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | VXLAN Network Identifier (VNI) | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 1: VXLAN Header 184 3. Generic Protocol Extension for VXLAN (VXLAN GPE) 186 3.1. VXLAN GPE Header 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | VXLAN Network Identifier (VNI) | Reserved | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2: VXLAN GPE Header 198 Flags (8 bits): The first 8 bits of the header are the flag field. 199 The bits designated "R" above are reserved flags. These MUST be 200 set to zero on transmission and ignored on receipt. 202 Version (Ver): Indicates VXLAN GPE protocol version. The initial 203 version is 0. If a receiver does not support the version 204 indicated it MUST drop the packet. 206 Instance Bit (I bit): The I bit MUST be set to indicate a valid VNI. 208 Next Protocol Bit (P bit): The P bit is set to indicate that the 209 Next Protocol field is present. 211 OAM Flag Bit (O bit): The O bit is set to indicate that the packet 212 is an OAM packet. 214 Next Protocol: This 8 bit field indicates the protocol header 215 immediately following the VXLAN GPE header. 217 VNI: This 24 bit field identifies the VXLAN overlay network the 218 inner packet belongs to. Inner packets belonging to different 219 VNIs cannot communicate with each other (unless explicitly allowed 220 by policy). 222 Reserved: Reserved fields MUST be set to zero on transmission and 223 ignored on receipt. 225 3.2. Multi Protocol Support 227 This draft defines the following two changes to the VXLAN header in 228 order to support multi-protocol encapsulation: 230 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 231 MUST be set to 1 to indicate the presence of the 8 bit next 232 protocol field. When P=1, the destination UDP port MUST be 4790. 234 P = 0 indicates that the payload MUST conform to VXLAN as defined 235 in [RFC7348], including destination UDP port. 237 Flag bit 5 was chosen as the P bit because this flag bit is 238 currently reserved in VXLAN. 240 Next Protocol Field: The lower 8 bits of the first word are used to 241 carry a next protocol. This next protocol field contains the 242 protocol of the encapsulated payload packet. A new protocol 243 registry will be requested from IANA, see section 9.2. 245 This draft defines the following Next Protocol values: 247 0x1 : IPv4 248 0x2 : IPv6 249 0x3 : Ethernet 250 0x4 : Network Service Header [NSH] 251 0x5 : Multiprotocol Label Switching [RFC3031]. Please see 252 [idrtun] for more details. 254 3.3. OAM Support 256 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 257 packet is an OAM packet and OAM processing MUST occur. Other header 258 fields including Next Protocol MUST adhere to the definitions in 259 section 3. The OAM protocol details are out of scope for this 260 document. As with the P-bit, bit 7 is currently a reserved flag in 261 VXLAN. 263 3.4. Version Bits 265 VXLAN GPE bits 2 and 3 are defined as version bits. These bits are 266 reserved in VXLAN. The version field is used to ensure backward 267 compatibility going forward with future VXLAN GPE updates. 269 The initial version for VXLAN GPE is 0. 271 4. Outer Encapsulations 273 In addition to the VXLAN GPE header, the packet is further 274 encapsulated in UDP and IP. Data centers based on Ethernet, will 275 then send this IP packet over Ethernet. 277 Outer UDP Header: 279 Destination UDP Port: IANA has assigned the value 4790 for the VXLAN 280 GPE UDP port. This well-known destination port is used when sending 281 VXLAN GPE encapsulated packets. 283 Source UDP Port: The source UDP port is used as entropy for devices 284 forwarding encapsulated packets across the underlay (ECMP for IP 285 routers, or load splitting for link aggregation by bridges). Tenant 286 traffic flows should all use the same source UDP port to lower the 287 chances of packet reordering by the underlay for a given flow. It is 288 recommended for VTEPs to generate this port number using a hash of 289 the inner packet headers. Implementations MAY use the entire 16 bit 290 source UDP port for entropy. 292 UDP Checksum: Source VTEPs MAY either calculate a valid checksum, or 293 if this is not possible, set the checksum to zero. When calculating 294 a checksum, it MUST be calculated across the entire packet (outer IP 295 header, UDP header, VXLAN GPE header and payload packet). All 296 receiving VTEPs must accept a checksum value of zero. If the 297 receiving VTEP is capable of validating the checksum, it MAY validate 298 a non-zero checksum and MUST discard the packet if the checksum is 299 determined to be invalid. 301 Outer IP Header: 303 This is the header used by the underlay network to deliver packets 304 between VTEPs. The destination IP address can be a unicast or a 305 multicast IP address. The source IP address must be the source VTEP 306 IP address which can be used to return tenant packets to the tenant 307 system source address within the inner packet header. 309 When the outer IP header is IPv4, VTEPs MUST set the DF bit. 311 Outer Ethernet Header: 313 Most data centers networks are built on Ethernet. Assuming the outer 314 IP packet is being sent across Ethernet, there will be an Ethernet 315 header used to deliver the IP packet to the next hop, which could be 316 the destination VTEP or be a router used to forward the IP packet 317 towards the destination VTEP. If VLANs are in use within the data 318 center, then this Ethernet header would also contain a VLAN tag. 320 The following figures show the entire stack of protocol headers that 321 would be seen on an Ethernet link carrying encapsulated packets from 322 a VTEP across the underlay network for both IPv4 and IPv6 based 323 underlay networks. 325 0 1 2 3 326 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 328 Outer Ethernet Header: 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Outer Destination MAC Address | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Outer Destination MAC Address | Outer Source MAC Address | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Outer Source MAC Address | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Ethertype = 0x0800 | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Outer IPv4 Header: 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 |Version| IHL |Type of Service| Total Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Identification |Flags| Fragment Offset | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Time to Live |Protocl=17(UDP)| Header Checksum | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Outer Source IPv4 Address | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Outer Destination IPv4 Address | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Outer UDP Header: 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Source Port | Dest Port = 4790 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | UDP Length | UDP Checksum | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 VXLAN GPE Header: 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | VXLAN Network Identifier (VNI) | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Payload: 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Depends on VXLAN GPE Next Protocol field above. | 371 | Note that if the payload is Ethernet, then the original | 372 | Ethernet Frame's FCS is not included. | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Frame Check Sequence: 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 3: Outer Headers for VXLAN GPE over IPv4 382 0 1 2 3 383 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 385 Outer Ethernet Header: 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Outer Destination MAC Address | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Outer Destination MAC Address | Outer Source MAC Address | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Outer Source MAC Address | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Ethertype = 0x86DD | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Outer IPv6 Header: 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 |Version| Traffic Class | Flow Label | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | | 405 + + 406 | | 407 + Outer Source IPv6 Address + 408 | | 409 + + 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 + + 414 | | 415 + Outer Destination IPv6 Address + 416 | | 417 + + 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Outer UDP Header: 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Source Port | Dest Port = 4790 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | UDP Length | UDP Checksum | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 VXLAN GPE Header: 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | VXLAN Network Identifier (VNI) | Reserved | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Payload: 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Depends on VXLAN GPE Next Protocol field above. | 438 | Note that if the payload is Ethernet, then the original | 439 | Ethernet Frame's FCS is not included. | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Frame Check Sequence: 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure X: Outer Headers for VXLAN GPE over IPv6 449 Figure 4: Outer Headers for VXLAN GPE over IPv6 451 4.1. Inner VLAN Tag Handling 453 If the inner packet (as indicated by the VXLAN GPE Next Protocol 454 field) is an Ethernet frame, it is recommended that it does not 455 contain a VLAN tag. In the most common scenarios, the tenant VLAN 456 tag is translated into a VXLAN Network Identifier. In these 457 scenarios, VTEPs should never send an inner Ethernet frame with a 458 VLAN tag, and a VTEP performing decapsulation should discard any 459 inner frames received with a VLAN tag. However, if the VTEPs are 460 specifically configured to support it for a specific VXLAN Network 461 Identifier, a VTEP may support transparent transport of the inner 462 VLAN tag between all tenant systems on that VNI. The VTEP never 463 looks at the value of the inner VLAN tag, but simply passes it across 464 the underlay. 466 4.2. Fragmentation Considerations 468 VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when 469 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer 470 IPv4 header. It is recommended that the underlay network be 471 configured to carry an MTU at least large enough to accommodate the 472 added encapsulation headers. It is recommended that VTEPs perform 473 Path MTU discovery [RFC1191] [RFC1981] to determine if the underlay 474 network can carry the encapsulated payload packet. 476 5. Backward Compatibility 478 5.1. VXLAN VTEP to VXLAN GPE VTEP 480 A VXLAN VTEP conforms to VXLAN frame format and uses UDP destination 481 port 4789 when sending traffic to VXLAN GPE VTEP. As per VXLAN, 482 reserved bits 5 and 7, VXLAN GPE P and O-bits respectively must be 483 set to zero. The remaining reserved bits must be zero, including the 484 VXLAN GPE version field, bits 2 and 3. The encapsulated payload MUST 485 be Ethernet. 487 5.2. VXLAN GPE VTEP to VXLAN VTEP 489 A VXLAN GPE VTEP MUST NOT encapsulate non-Ethernet frames to a VXLAN 490 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN 491 GPE VTEP MUST conform to VXLAN frame format and hence will set the P 492 bit to 0, the Next Protocol to 0 and use UDP destination port 4789. 493 A VXLAN GPE VTEP MUST also set O = 0 and Ver = 0 when encapsulating 494 Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP will treat 495 this packet as a VXLAN packet. 497 A method for determining the capabilities of a VXLAN VTEP (GPE or 498 non-GPE) is out of the scope of this draft. 500 5.3. VXLAN GPE UDP Ports 502 VXLAN GPE uses a IANA assigned UDP destination port, 4790, when 503 sending traffic to VXLAN GPE VTEPs. 505 5.4. VXLAN GPE and Encapsulated IP Header Fields 507 When encapsulating and decapsulating IPv4 and IPv6 packets, certain 508 fields, such as IPv4 Time to Live (TTL) from the inner IP header need 509 to be considered. VXLAN GPE IP encapsulation and decapsulation 510 utilizes the techniques described in [RFC6830], section 5.3. 512 6. VXLAN GPE Examples 514 This section provides three examples of protocols encapsulated using 515 the Generic Protocol Extension for VXLAN described in this document. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |R|R|0|0|I|1|R|0| Reserved | NP = IPv4 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | VXLAN Network Identifier (VNI) | Reserved | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Original IPv4 Packet | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 Figure 5: IPv4 and VXLAN GPE 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 |R|R|0|0|I|1|R|0| Reserved | NP = IPv6 | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | VXLAN Network Identifier (VNI) | Reserved | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Original IPv6 Packet | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 6: IPv6 and VXLAN GPE 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 |R|R|0|0|I|1|R|0| Reserved |NP = Ethernet | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | VXLAN Network Identifier (VNI) | Reserved | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Original Ethernet Frame | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 7: Ethernet and VXLAN GPE 553 7. Security Considerations 555 VXLAN's security is focused on issues around L2 encapsulation into 556 L3. With VXLAN GPE, issues such as spoofing, flooding, and traffic 557 redirection are dependent on the particular protocol payload 558 encapsulated. 560 8. Acknowledgments 562 A special thank you goes to Dino Farinacci for his guidance and 563 detailed review. 565 9. IANA Considerations 567 9.1. UDP Port 569 UDP 4790 port has been assigned by IANA for VXLAN GPE. 571 9.2. VXLAN GPE Next Protocol 573 IANA is requested to set up a registry of "Next Protocol". These are 574 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in 575 this draft. New values are assigned via Standards Action [RFC5226]. 577 +---------------+-------------+---------------+ 578 | Next Protocol | Description | Reference | 579 +---------------+-------------+---------------+ 580 | 0 | Reserved | This document | 581 | | | | 582 | 1 | IPv4 | This document | 583 | | | | 584 | 2 | IPv6 | This document | 585 | | | | 586 | 3 | Ethernet | This document | 587 | | | | 588 | 4 | NSH | This document | 589 | | | | 590 | 5 | MPLS | This document | 591 | | | | 592 | 6..253 | Unassigned | | 593 +---------------+-------------+---------------+ 595 Table 1 597 9.3. VXLAN GPE Flag and Reserved Bits 599 There are ten flag bits at the beginning of the VXLAN GPE header, 600 followed by 16 reserved bits and an 8-bit reserved field at the end 601 of the header. New bits are assigned via Standards Action [RFC5226]. 603 Bits 0-1 - Reserved 604 Bits 2-3 - Version 605 Bit 4 - Instance ID (I bit) 606 Bit 5 - Next Protocol (P bit) 607 Bit 6 - Reserved 608 Bit 7 - OAM (O bit) 609 Bits 8-23 - Reserved 610 Bits 24-31 in the 2nd Word -- Reserved 611 Reserved bits/fields MUST be set to 0 by the sender and ignored by 612 the receiver. 614 10. References 616 10.1. Normative References 618 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 619 DOI 10.17487/RFC0768, August 1980, 620 . 622 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 623 DOI 10.17487/RFC0791, September 1981, 624 . 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 628 RFC2119, March 1997, 629 . 631 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 632 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 633 DOI 10.17487/RFC5226, May 2008, 634 . 636 10.2. Informative References 638 [NSH] Quinn, P., Ed. and U. Elzur, Ed., "Network Service 639 Header", 2015. 641 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 642 DOI 10.17487/RFC1191, November 1990, 643 . 645 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 646 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, 647 August 1996, . 649 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 650 Label Switching Architecture", RFC 3031, DOI 10.17487/ 651 RFC3031, January 2001, 652 . 654 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 655 Cheshire, "Internet Assigned Numbers Authority (IANA) 656 Procedures for the Management of the Service Name and 657 Transport Protocol Port Number Registry", BCP 165, 658 RFC 6335, DOI 10.17487/RFC6335, August 2011, 659 . 661 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 662 Locator/ID Separation Protocol (LISP)", RFC 6830, 663 DOI 10.17487/RFC6830, January 2013, 664 . 666 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 667 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 668 eXtensible Local Area Network (VXLAN): A Framework for 669 Overlaying Virtualized Layer 2 Networks over Layer 3 670 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 671 . 673 [idrtun] Rosen, E., Ed., Patel, K., and G. Van de Velde, "Using the 674 BGP Tunnel Encapsulation Attribute without the BGP 675 Encapsulation SAFI", 2015. 677 Authors' Addresses 679 Paul Quinn 680 Cisco Systems, Inc. 682 Email: paulq@cisco.com 684 Rajeev Manur 685 Broadcom 687 Email: rmanur@broadcom.com 689 Larry Kreeger 690 Cisco Systems, Inc. 692 Email: kreeger@cisco.com 694 Darrel Lewis 695 Cisco Systems, Inc. 697 Email: darlewis@cisco.com 699 Fabio Maino 700 Cisco Systems, Inc. 702 Email: fmaino@cisco.com 704 Michael Smith 705 Cisco Systems, Inc. 707 Email: michsmit@cisco.com 709 Puneet Agarwal 710 Innovium, Inc 712 Email: puneet@acm.org 713 Lucy Yong 714 Huawei USA 716 Email: lucy.yong@huawei.com 718 Xiaohu Xu 719 Huawei Technologies 721 Email: xuxiaohu@huawei.com 723 Uri Elzur 724 Intel 726 Email: uri.elzur@intel.com 728 Pankaj Garg 729 Microsoft 731 Email: Garg.Pankaj@microsoft.com 733 David Melman 734 Marvell 736 Email: davidme@marvell.com