idnits 2.17.1 draft-ietf-nvo3-vxlan-gpe-03.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 (October 25, 2016) is 2733 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) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Downref: Normative reference to an Informational RFC: RFC 7348 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-10 Summary: 4 errors (**), 0 flaws (~~), 3 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: Standards Track L. Kreeger, Ed. 5 Expires: April 28, 2017 6 U. Elzur, Ed. 7 Intel 8 October 25, 2016 10 Generic Protocol Extension for VXLAN 11 draft-ietf-nvo3-vxlan-gpe-03 13 Abstract 15 This draft describes extending Virtual eXtensible Local Area Network 16 (VXLAN), via changes to the VXLAN header, with three new 17 capabilities: support for multi-protocol encapsulation, operations, 18 administration and management (OAM) signaling and explicit 19 versioning. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 28, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. VXLAN Without Protocol Extension . . . . . . . . . . . . . . 3 63 3. Generic Protocol Extension for VXLAN (VXLAN GPE) . . . . . . 4 64 3.1. VXLAN GPE Header . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Multi Protocol Support . . . . . . . . . . . . . . . . . 5 66 3.3. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. Version Bits . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Outer Encapsulations . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Inner VLAN Tag Handling . . . . . . . . . . . . . . . . . 10 70 4.2. Fragmentation Considerations . . . . . . . . . . . . . . 10 71 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 72 5.1. VXLAN VTEP to VXLAN GPE VTEP . . . . . . . . . . . . . . 10 73 5.2. VXLAN GPE VTEP to VXLAN VTEP . . . . . . . . . . . . . . 11 74 5.3. VXLAN GPE UDP Ports . . . . . . . . . . . . . . . . . . . 11 75 5.4. VXLAN GPE and Encapsulated IP Header Fields . . . . . . . 11 76 6. VXLAN GPE Examples . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 13 82 10.2. VXLAN GPE Next Protocol . . . . . . . . . . . . . . . . 14 83 10.3. VXLAN GPE Flag and Reserved Bits . . . . . . . . . . . . 14 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 11.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Virtual eXtensible Local Area Network VXLAN [RFC7348] defines an 92 encapsulation format that encapsulates Ethernet frames in an outer 93 UDP/IP transport. As data centers evolve, the need to carry other 94 protocols encapsulated in an IP packet is required, as well as the 95 need to provide increased visibility and diagnostic capabilities 96 within the overlay. The VXLAN header does not specify the protocol 97 being encapsulated and therefore is currently limited to 98 encapsulating only Ethernet frame payload, nor does it provide the 99 ability to define OAM protocols. In addition, [RFC6335] requires 100 that new transports not use transport layer port numbers to identify 101 tunnel payload, rather it encourages encapsulations to use their own 102 identifiers for this purpose. VXLAN GPE is intended to extend the 103 existing VXLAN protocol to provide protocol typing, OAM, and 104 versioning capabilities. 106 The Version and OAM bits are introduced in Section 3, and the choice 107 of location for these fields is driven by minimizing the impact on 108 existing deployed hardware. 110 In order to facilitate deployments of VXLAN GPE with hardware 111 currently deployed to support VXLAN, changes from legacy VXLAN have 112 been kept to a minimum. Section 5 provides a detailed discussion 113 about how VXLAN GPE addresses the requirement for backward 114 compatibility with VXLAN. 116 2. VXLAN Without Protocol Extension 118 VXLAN provides a method of creating multi-tenant overlay networks by 119 encapsulating packets in IP/UDP along with a header containing a 120 network identifier which is used to isolate tenant traffic in each 121 overlay network from each other. This allows the overlay networks to 122 run over an existing IP network. 124 Through this encapsulation, VXLAN creates stateless tunnels between 125 VXLAN Tunnel End Points (VTEPs) which are responsible for adding/ 126 removing the IP/UDP/VXLAN headers and providing tenant traffic 127 isolation based on the VXLAN Network Identifier (VNI). Tenant 128 systems are unaware that their networking service is being provided 129 by an overlay. 131 When encapsulating packets, a VTEP must know the IP address of the 132 proper remote VTEP at the far end of the tunnel that can deliver the 133 inner packet to the Tenant System corresponding to the inner 134 destination address. In the case of tenant multicast or broadcast, 135 the outer IP address may be an IP multicast group address, or the 136 VTEP may replicate the packet and send it to all known VTEPs. If 137 multicast is used in the underlay network to send encapsulated 138 packets to remote VTEPs, Any Source Multicast is used and each VTEP 139 serving a particular VNI must perform a (*, G) join to the same group 140 IP address. 142 Inner to outer address mapping can be determined in two ways. One is 143 source based learning in the data plane, and the other is 144 distribution via a control plane. 146 Source based learning requires a receiving VTEP to create an inner to 147 outer address mapping by gleaning the information from the received 148 packets by correlating the inner source address to the outer source 149 IP address. When a mapping does not exist, a VTEP forwards the 150 packets to all remote VTEPs participating in the VNI by using IP 151 multicast in the IP underlay network. Each VTEP must be configured 152 with the IP multicast address to use for each VNI. How this occurs 153 is out of scope. 155 The control plane used to distribute inner to outer mappings is also 156 out of scope. It could use a centralized authority or be 157 distributed, or use a hybrid. 159 The VXLAN Network Identifier (VNI) provides scoping for the addresses 160 in the header of the encapsulated PDU. If the encapsulated packet is 161 an Ethernet frame, this means the Ethernet MAC addresses are only 162 unique within a given VNI and may overlap with MAC addresses within a 163 different VNI. If the encapsulated packet is an IP packet, this 164 means the IP addresses are only unique within that VNI. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 |R|R|R|R|I|R|R|R| Reserved | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | VXLAN Network Identifier (VNI) | Reserved | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: VXLAN Header 176 3. Generic Protocol Extension for VXLAN (VXLAN GPE) 178 3.1. VXLAN GPE Header 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | VXLAN Network Identifier (VNI) | Reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2: VXLAN GPE Header 190 Flags (8 bits): The first 8 bits of the header are the flag field. 191 The bits designated "R" above are reserved flags. These MUST be 192 set to zero on transmission and ignored on receipt. 194 Version (Ver): Indicates VXLAN GPE protocol version. The initial 195 version is 0. If a receiver does not support the version 196 indicated it MUST drop the packet. 198 Instance Bit (I bit): The I bit MUST be set to indicate a valid VNI. 200 Next Protocol Bit (P bit): The P bit is set to indicate that the 201 Next Protocol field is present. 203 OAM Flag Bit (O bit): The O bit is set to indicate that the packet 204 is an OAM packet. 206 Next Protocol: This 8 bit field indicates the protocol header 207 immediately following the VXLAN GPE header. 209 VNI: This 24 bit field identifies the VXLAN overlay network the 210 inner packet belongs to. Inner packets belonging to different 211 VNIs cannot communicate with each other (unless explicitly allowed 212 by policy). 214 Reserved: Reserved fields MUST be set to zero on transmission and 215 ignored on receipt. 217 3.2. Multi Protocol Support 219 This draft defines the following two changes to the VXLAN header in 220 order to support multi-protocol encapsulation: 222 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 223 MUST be set to 1 to indicate the presence of the 8 bit next 224 protocol field. 226 When UDP dest port=4790, P = 0 the "Next Protocol" field must be 227 set to zero and the payload MUST be ETHERNET(L2) as defined by 228 [RFC7348]. 230 Flag bit 5 was chosen as the P bit because this flag bit is 231 currently reserved in VXLAN. 233 Next Protocol Field: The lower 8 bits of the first word are used to 234 carry a next protocol. This next protocol field contains the 235 protocol of the encapsulated payload packet. A new protocol 236 registry will be requested from IANA, see section 9.2. 238 This draft defines the following Next Protocol values: 240 0x1 : IPv4 242 0x2 : IPv6 244 0x3 : Ethernet 246 0x4 : Network Service Header [I-D.ietf-sfc-nsh] 248 0x5 : Multiprotocol Label Switching [RFC3031]. Please see 249 [I-D.ietf-idr-tunnel-encaps] for more details. 251 3.3. OAM Support 253 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 254 packet is an OAM packet and OAM processing MUST occur. Other header 255 fields including Next Protocol MUST adhere to the definitions in 256 Section 3. The OAM protocol details are out of scope for this 257 document. As with the P-bit, bit 7 is currently a reserved flag in 258 VXLAN. 260 3.4. Version Bits 262 VXLAN GPE bits 2 and 3 are defined as version bits. These bits are 263 reserved in VXLAN. The version field is used to ensure backward 264 compatibility going forward with future VXLAN GPE updates. 266 The initial version for VXLAN GPE is 0. 268 4. Outer Encapsulations 270 In addition to the VXLAN GPE header, the packet is further 271 encapsulated in UDP and IP. Data centers based on Ethernet, will 272 then send this IP packet over Ethernet. 274 Outer UDP Header: 276 Destination UDP Port: IANA has assigned the value 4790 for the VXLAN 277 GPE UDP port. This well-known destination port is used when sending 278 VXLAN GPE encapsulated packets. 280 Source UDP Port: The source UDP port is used as entropy for devices 281 forwarding encapsulated packets across the underlay (ECMP for IP 282 routers, or load splitting for link aggregation by bridges). Tenant 283 traffic flows should all use the same source UDP port to lower the 284 chances of packet reordering by the underlay for a given flow. It is 285 recommended for VTEPs to generate this port number using a hash of 286 the inner packet headers. Implementations MAY use the entire 16 bit 287 source UDP port for entropy. 289 UDP Checksum: Source VTEPs MAY either calculate a valid checksum, or 290 if this is not possible, set the checksum to zero. When calculating 291 a checksum, it MUST be calculated across the entire packet (outer IP 292 header, UDP header, VXLAN GPE header and payload packet). All 293 receiving VTEPs must accept a checksum value of zero. If the 294 receiving VTEP is capable of validating the checksum, it MAY validate 295 a non-zero checksum and MUST discard the packet if the checksum is 296 determined to be invalid. 298 Outer IP Header: 300 This is the header used by the underlay network to deliver packets 301 between VTEPs. The destination IP address can be a unicast or a 302 multicast IP address. The source IP address must be the source VTEP 303 IP address which can be used to return tenant packets to the tenant 304 system source address within the inner packet header. 306 When the outer IP header is IPv4, VTEPs MUST set the DF bit. 308 Outer Ethernet Header: 310 Most data centers networks are built on Ethernet. Assuming the outer 311 IP packet is being sent across Ethernet, there will be an Ethernet 312 header used to deliver the IP packet to the next hop, which could be 313 the destination VTEP or be a router used to forward the IP packet 314 towards the destination VTEP. If VLANs are in use within the data 315 center, then this Ethernet header would also contain a VLAN tag. 317 The following figures show the entire stack of protocol headers that 318 would be seen on an Ethernet link carrying encapsulated packets from 319 a VTEP across the underlay network for both IPv4 and IPv6 based 320 underlay networks. 322 0 1 2 3 323 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 325 Outer Ethernet Header: 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Outer Destination MAC Address | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Outer Destination MAC Address | Outer Source MAC Address | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Outer Source MAC Address | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Ethertype = 0x0800 | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Outer IPv4 Header: 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |Version| IHL |Type of Service| Total Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Identification |Flags| Fragment Offset | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Time to Live |Protocl=17(UDP)| Header Checksum | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Outer Source IPv4 Address | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Outer Destination IPv4 Address | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Outer UDP Header: 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Source Port | Dest Port = 4790 | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | UDP Length | UDP Checksum | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 VXLAN GPE Header: 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | VXLAN Network Identifier (VNI) | Reserved | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Payload: 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Depends on VXLAN GPE Next Protocol field above. | 367 | Note that if the payload is Ethernet, then the original | 368 | Ethernet Frame's FCS is not included. | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Frame Check Sequence: 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 3: Outer Headers for VXLAN GPE over IPv4 378 0 1 2 3 379 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 381 Outer Ethernet Header: 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Outer Destination MAC Address | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Outer Destination MAC Address | Outer Source MAC Address | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Outer Source MAC Address | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Ethertype = 0x86DD | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Outer IPv6 Header: 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 |Version| Traffic Class | Flow Label | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 + + 402 | | 403 + Outer Source IPv6 Address + 404 | | 405 + + 406 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 + + 410 | | 411 + Outer Destination IPv6 Address + 412 | | 413 + + 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Outer UDP Header: 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Source Port | Dest Port = 4790 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | UDP Length | UDP Checksum | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 VXLAN GPE Header: 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | VXLAN Network Identifier (VNI) | Reserved | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Payload: 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Depends on VXLAN GPE Next Protocol field above. | 434 | Note that if the payload is Ethernet, then the original | 435 | Ethernet Frame's FCS is not included. | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Frame Check Sequence: 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4: Outer Headers for VXLAN GPE over IPv6 445 4.1. Inner VLAN Tag Handling 447 If the inner packet (as indicated by the VXLAN GPE Next Protocol 448 field) is an Ethernet frame, it is recommended that it does not 449 contain a VLAN tag. In the most common scenarios, the tenant VLAN 450 tag is translated into a VXLAN Network Identifier. In these 451 scenarios, VTEPs should never send an inner Ethernet frame with a 452 VLAN tag, and a VTEP performing decapsulation should discard any 453 inner frames received with a VLAN tag. However, if the VTEPs are 454 specifically configured to support it for a specific VXLAN Network 455 Identifier, a VTEP may support transparent transport of the inner 456 VLAN tag between all tenant systems on that VNI. The VTEP never 457 looks at the value of the inner VLAN tag, but simply passes it across 458 the underlay. 460 4.2. Fragmentation Considerations 462 VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when 463 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer 464 IPv4 header. It is recommended that the underlay network be 465 configured to carry an MTU at least large enough to accommodate the 466 added encapsulation headers. It is recommended that VTEPs perform 467 Path MTU discovery [RFC1191] [RFC1981] to determine if the underlay 468 network can carry the encapsulated payload packet. 470 5. Backward Compatibility 472 5.1. VXLAN VTEP to VXLAN GPE VTEP 474 A VXLAN VTEP conforms to VXLAN frame format and uses UDP destination 475 port 4789 when sending traffic to VXLAN GPE VTEP. As per VXLAN, 476 reserved bits 5 and 7, VXLAN GPE P and O-bits respectively must be 477 set to zero. The remaining reserved bits must be zero, including the 478 VXLAN GPE version field, bits 2 and 3. The encapsulated payload MUST 479 be Ethernet. 481 5.2. VXLAN GPE VTEP to VXLAN VTEP 483 A VXLAN GPE VTEP MUST NOT encapsulate non-Ethernet frames to a VXLAN 484 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN 485 GPE VTEP MUST conform to VXLAN frame format and hence will set the P 486 bit to 0, the Next Protocol to 0 and use UDP destination port 4789. 487 A VXLAN GPE VTEP MUST also set O = 0 and Ver = 0 when encapsulating 488 Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP will treat 489 this packet as a VXLAN packet. 491 A method for determining the capabilities of a VXLAN VTEP (GPE or 492 non-GPE) is out of the scope of this draft. 494 5.3. VXLAN GPE UDP Ports 496 VXLAN GPE uses a IANA assigned UDP destination port, 4790, when 497 sending traffic to VXLAN GPE VTEPs. 499 5.4. VXLAN GPE and Encapsulated IP Header Fields 501 When encapsulating and decapsulating IPv4 and IPv6 packets, certain 502 fields, such as IPv4 Time to Live (TTL) from the inner IP header need 503 to be considered. VXLAN GPE IP encapsulation and decapsulation 504 utilizes the techniques described in [RFC6830], section 5.3. 506 6. VXLAN GPE Examples 508 This section provides three examples of protocols encapsulated using 509 the Generic Protocol Extension for VXLAN described in this document. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 |R|R|0|0|I|1|R|0| Reserved | NP = IPv4 | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | VXLAN Network Identifier (VNI) | Reserved | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Original IPv4 Packet | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 5: IPv4 and VXLAN GPE 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |R|R|0|0|I|1|R|0| Reserved | NP = IPv6 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | VXLAN Network Identifier (VNI) | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Original IPv6 Packet | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Figure 6: IPv6 and VXLAN GPE 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |R|R|0|0|I|1|R|0| Reserved |NP = Ethernet | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | VXLAN Network Identifier (VNI) | Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Original Ethernet Frame | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 7: Ethernet and VXLAN GPE 547 7. Security Considerations 549 VXLAN's security is focused on issues around L2 encapsulation into 550 L3. With VXLAN GPE, issues such as spoofing, flooding, and traffic 551 redirection are dependent on the particular protocol payload 552 encapsulated. 554 8. Contributors 555 Paul Quinn 556 Cisco Systems 557 paulq@cisco.com 559 Rajeev Manur 560 Broadcom 561 rmanur@broadcom.com 563 Michael Smith 564 Cisco Systems 565 michsmit@cisco.com 567 Darrel Lewis 568 Cisco Systems 569 darlewis@cisco.com 571 Puneet Agarwal 572 Innovium, Inc 573 puneet@acm.org 575 Lucy Yong 576 Huawei USA 577 lucy.yong@huawei.com 579 Xiaohu Xu 580 Huawei Technologies 581 xuxiaohu@huawei.com 583 Pankaj Garg 584 Microsoft 585 pankajg@microsoft.com 587 David Melman 588 Marvell 589 davidme@marvell.com 591 9. Acknowledgments 593 A special thank you goes to Dino Farinacci for his guidance and 594 detailed review. 596 10. IANA Considerations 598 10.1. UDP Port 600 UDP 4790 port has been assigned by IANA for VXLAN GPE. 602 10.2. VXLAN GPE Next Protocol 604 IANA is requested to set up a registry of "Next Protocol". These are 605 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in 606 this draft. New values are assigned via Standards Action [RFC5226]. 608 +---------------+-------------+---------------+ 609 | Next Protocol | Description | Reference | 610 +---------------+-------------+---------------+ 611 | 0 | Reserved | This Document | 612 | 1 | IPv4 | This Document | 613 | 2 | IPv6 | This Document | 614 | 3 | Ethernet | This Document | 615 | 4 | NSH | This Document | 616 | 5 | MPLS | This Document | 617 | 6..253 | Unassigned | | 618 +---------------+-------------+---------------+ 620 10.3. VXLAN GPE Flag and Reserved Bits 622 There are ten flag bits at the beginning of the VXLAN GPE header, 623 followed by 16 reserved bits and an 8-bit reserved field at the end 624 of the header. New bits are assigned via Standards Action [RFC5226]. 626 Bits 0-1 - Reserved 628 Bits 2-3 - Version 630 Bit 4 - Instance ID (I bit) 632 Bit 5 - Next Protocol (P bit) 634 Bit 6 - Reserved 636 Bit 7 - OAM (O bit) 638 Bit 8-23 - Reserved 640 Bits 24-31 in the 2nd Word -- Reserved 642 Reserved bits/fields MUST be set to 0 by the sender and ignored by 643 the receiver. 645 11. References 646 11.1. Normative References 648 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 649 DOI 10.17487/RFC1191, November 1990, 650 . 652 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 653 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 654 1996, . 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, 659 . 661 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 662 Label Switching Architecture", RFC 3031, 663 DOI 10.17487/RFC3031, January 2001, 664 . 666 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 667 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 668 DOI 10.17487/RFC5226, May 2008, 669 . 671 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 672 Cheshire, "Internet Assigned Numbers Authority (IANA) 673 Procedures for the Management of the Service Name and 674 Transport Protocol Port Number Registry", BCP 165, 675 RFC 6335, DOI 10.17487/RFC6335, August 2011, 676 . 678 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 679 Locator/ID Separation Protocol (LISP)", RFC 6830, 680 DOI 10.17487/RFC6830, January 2013, 681 . 683 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 684 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 685 eXtensible Local Area Network (VXLAN): A Framework for 686 Overlaying Virtualized Layer 2 Networks over Layer 3 687 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 688 . 690 11.2. Informative References 692 [I-D.ietf-idr-tunnel-encaps] 693 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 694 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-02 695 (work in progress), May 2016. 697 [I-D.ietf-sfc-nsh] 698 Quinn, P. and U. Elzur, "Network Service Header", draft- 699 ietf-sfc-nsh-10 (work in progress), September 2016. 701 Authors' Addresses 703 Fabio Maino (Editor) 704 Cisco Systems 706 Email: fmaino@cisco.com 708 Larry Kreeger (editor) 710 Email: lkreeger@gmail.com 712 Uri Elzur (editor) 713 Intel 715 Email: uri.elzur@intel.com