idnits 2.17.1 draft-ietf-nvo3-vxlan-gpe-05.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 30, 2017) is 2369 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 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-08 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-07 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-27 == Outdated reference: A later version (-02) exists of draft-lemon-vxlan-gpe-gbp-00 Summary: 3 errors (**), 0 flaws (~~), 5 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: May 3, 2018 6 U. Elzur, Ed. 7 Intel 8 October 30, 2017 10 Generic Protocol Extension for VXLAN 11 draft-ietf-nvo3-vxlan-gpe-05 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 May 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 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. Replicated BUM Traffic . . . . . . . . . . . . . . . . . 6 67 3.4. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.5. Version Bits . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Outer Encapsulations . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Inner VLAN Tag Handling . . . . . . . . . . . . . . . . . 11 71 4.2. Fragmentation Considerations . . . . . . . . . . . . . . 11 72 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 73 5.1. VXLAN VTEP to VXLAN GPE VTEP . . . . . . . . . . . . . . 11 74 5.2. VXLAN GPE VTEP to VXLAN VTEP . . . . . . . . . . . . . . 11 75 5.3. VXLAN GPE UDP Ports . . . . . . . . . . . . . . . . . . . 12 76 5.4. VXLAN GPE and Encapsulated IP Header Fields . . . . . . . 12 77 6. VXLAN GPE Examples . . . . . . . . . . . . . . . . . . . . . 12 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10.1. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.2. VXLAN GPE Next Protocol . . . . . . . . . . . . . . . . 15 84 10.3. VXLAN GPE Flag and Reserved Bits . . . . . . . . . . . . 15 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 11.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Virtual eXtensible Local Area Network VXLAN [RFC7348] defines an 93 encapsulation format that encapsulates Ethernet frames in an outer 94 UDP/IP transport. As data centers evolve, the need to carry other 95 protocols encapsulated in an IP packet is required, as well as the 96 need to provide increased visibility and diagnostic capabilities 97 within the overlay. The VXLAN header does not specify the protocol 98 being encapsulated and therefore is currently limited to 99 encapsulating only Ethernet frame payload, nor does it provide the 100 ability to define OAM protocols. In addition, [RFC6335] requires 101 that new transports not use transport layer port numbers to identify 102 tunnel payload, rather it encourages encapsulations to use their own 103 identifiers for this purpose. VXLAN GPE is intended to extend the 104 existing VXLAN protocol to provide protocol typing, OAM, and 105 versioning capabilities. 107 The Version and OAM bits are introduced in Section 3, and the choice 108 of location for these fields is driven by minimizing the impact on 109 existing deployed hardware. 111 In order to facilitate deployments of VXLAN GPE with hardware 112 currently deployed to support VXLAN, changes from legacy VXLAN have 113 been kept to a minimum. Section 5 provides a detailed discussion 114 about how VXLAN GPE addresses the requirement for backward 115 compatibility with VXLAN. 117 2. VXLAN Without Protocol Extension 119 VXLAN provides a method of creating multi-tenant overlay networks by 120 encapsulating packets in IP/UDP along with a header containing a 121 network identifier which is used to isolate tenant traffic in each 122 overlay network from each other. This allows the overlay networks to 123 run over an existing IP network. 125 Through this encapsulation, VXLAN creates stateless tunnels between 126 VXLAN Tunnel End Points (VTEPs) which are responsible for adding/ 127 removing the IP/UDP/VXLAN headers and providing tenant traffic 128 isolation based on the VXLAN Network Identifier (VNI). Tenant 129 systems are unaware that their networking service is being provided 130 by an overlay. 132 When encapsulating packets, a VTEP must know the IP address of the 133 proper remote VTEP at the far end of the tunnel that can deliver the 134 inner packet to the Tenant System corresponding to the inner 135 destination address. In the case of tenant multicast or broadcast, 136 the outer IP address may be an IP multicast group address, or the 137 VTEP may replicate the packet and send it to all known VTEPs. If 138 multicast is used in the underlay network to send encapsulated 139 packets to remote VTEPs, Any Source Multicast is used and each VTEP 140 serving a particular VNI must perform a (*, G) join to the same group 141 IP address. 143 Inner to outer address mapping can be determined in two ways. One is 144 source based learning in the data plane, and the other is 145 distribution via a control plane. 147 Source based learning requires a receiving VTEP to create an inner to 148 outer address mapping by gleaning the information from the received 149 packets by correlating the inner source address to the outer source 150 IP address. When a mapping does not exist, a VTEP forwards the 151 packets to all remote VTEPs participating in the VNI by using IP 152 multicast in the IP underlay network. Each VTEP must be configured 153 with the IP multicast address to use for each VNI. How this occurs 154 is out of scope. 156 The control plane used to distribute inner to outer mappings is also 157 out of scope. It could use a centralized authority or be 158 distributed, or use a hybrid. 160 The VXLAN Network Identifier (VNI) provides scoping for the addresses 161 in the header of the encapsulated PDU. If the encapsulated packet is 162 an Ethernet frame, this means the Ethernet MAC addresses are only 163 unique within a given VNI and may overlap with MAC addresses within a 164 different VNI. If the encapsulated packet is an IP packet, this 165 means the IP addresses are only unique within that VNI. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |R|R|R|R|I|R|R|R| Reserved | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | VXLAN Network Identifier (VNI) | Reserved | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: VXLAN Header 177 3. Generic Protocol Extension for VXLAN (VXLAN GPE) 179 3.1. VXLAN GPE Header 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |R|R|Ver|I|P|B|O| Reserved |Next Protocol | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | VXLAN Network Identifier (VNI) | Reserved | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 2: VXLAN GPE Header 191 Flags (8 bits): The first 8 bits of the header are the flag field. 192 The bits designated "R" above are reserved flags. These MUST be 193 set to zero on transmission and ignored on receipt. 195 Version (Ver): Indicates VXLAN GPE protocol version. The initial 196 version is 0. If a receiver does not support the version 197 indicated it MUST drop the packet. 199 Instance Bit (I bit): The I bit MUST be set to indicate a valid VNI. 201 Next Protocol Bit (P bit): The P bit is set to indicate that the 202 Next Protocol field is present. 204 BUM Traffic Bit (B bit): The B bit is set to indicate that this is 205 ingress-replicated BUM Traffic (ie, Broadcast, Unknown unicast, or 206 Multicast). 208 OAM Flag Bit (O bit): The O bit is set to indicate that the packet 209 is an OAM packet. 211 Next Protocol: This 8 bit field indicates the protocol header 212 immediately following the VXLAN GPE header. 214 VNI: This 24 bit field identifies the VXLAN overlay network the 215 inner packet belongs to. Inner packets belonging to different 216 VNIs cannot communicate with each other (unless explicitly allowed 217 by policy). 219 Reserved: Reserved fields MUST be set to zero on transmission and 220 ignored on receipt. 222 3.2. Multi Protocol Support 224 This draft defines the following two changes to the VXLAN header in 225 order to support multi-protocol encapsulation: 227 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 228 MUST be set to 1 to indicate the presence of the 8 bit next 229 protocol field. 231 When UDP dest port=4790, P = 0 the "Next Protocol" field must be 232 set to zero and the payload MUST be ETHERNET(L2) as defined by 233 [RFC7348]. 235 Flag bit 5 was chosen as the P bit because this flag bit is 236 currently reserved in VXLAN. 238 Next Protocol Field: The lower 8 bits of the first word are used to 239 carry a next protocol. This next protocol field contains the 240 protocol of the encapsulated payload packet. A new protocol 241 registry will be requested from IANA, see section 9.2. 243 This draft defines the following Next Protocol values: 245 0x1 : IPv4 247 0x2 : IPv6 249 0x3 : Ethernet 251 0x4 : Network Service Header [I-D.ietf-sfc-nsh] 253 0x5 : Multiprotocol Label Switching [RFC3031]. Please see 254 [I-D.ietf-idr-tunnel-encaps] for more details. 256 0x6: Group-Based Policy (GBP) [I-D.lemon-vxlan-gpe-gbp]. 258 0x7: virtual Broadband Network Gateway (vBNG) 259 [I-D.huang-nvo3-vxlan-gpe-extension-for-vbng]. 261 3.3. Replicated BUM Traffic 263 Flag bit 6 is defined as the B bit. When the B bit is set to 1, the 264 packet is marked as an an ingress-replicated BUM Traffic (i.e. 265 Broadcast, Unknown unicast, or Multicast) to help egress VTEP to 266 differentiate between known and unknown unicast. The details of 267 using the B bit are out of scope for this document, but please see 268 [I-D.ietf-bess-evpn-overlay] for an example in the EVPN context. As 269 with the P-bit, bit 6 is currently a reserved flag in VXLAN. 271 3.4. OAM Support 273 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 274 packet is an OAM packet and OAM processing MUST occur. Other header 275 fields including Next Protocol MUST adhere to the definitions in 276 Section 3. The OAM protocol details are out of scope for this 277 document. As with the P-bit, bit 7 is currently a reserved flag in 278 VXLAN. 280 3.5. Version Bits 282 VXLAN GPE bits 2 and 3 are defined as version bits. These bits are 283 reserved in VXLAN. The version field is used to ensure backward 284 compatibility going forward with future VXLAN GPE updates. 286 The initial version for VXLAN GPE is 0. 288 4. Outer Encapsulations 290 In addition to the VXLAN GPE header, the packet is further 291 encapsulated in UDP and IP. Data centers based on Ethernet, will 292 then send this IP packet over Ethernet. 294 Outer UDP Header: 296 Destination UDP Port: IANA has assigned the value 4790 for the VXLAN 297 GPE UDP port. This well-known destination port is used when sending 298 VXLAN GPE encapsulated packets. 300 Source UDP Port: The source UDP port is used as entropy for devices 301 forwarding encapsulated packets across the underlay (ECMP for IP 302 routers, or load splitting for link aggregation by bridges). Tenant 303 traffic flows should all use the same source UDP port to lower the 304 chances of packet reordering by the underlay for a given flow. It is 305 recommended for VTEPs to generate this port number using a hash of 306 the inner packet headers. Implementations MAY use the entire 16 bit 307 source UDP port for entropy. 309 UDP Checksum: Source VTEPs MAY either calculate a valid checksum, or 310 if this is not possible, set the checksum to zero. When calculating 311 a checksum, it MUST be calculated across the entire packet (outer IP 312 header, UDP header, VXLAN GPE header and payload packet). All 313 receiving VTEPs must accept a checksum value of zero. If the 314 receiving VTEP is capable of validating the checksum, it MAY validate 315 a non-zero checksum and MUST discard the packet if the checksum is 316 determined to be invalid. 318 Outer IP Header: 320 This is the header used by the underlay network to deliver packets 321 between VTEPs. The destination IP address can be a unicast or a 322 multicast IP address. The source IP address must be the source VTEP 323 IP address which can be used to return tenant packets to the tenant 324 system source address within the inner packet header. 326 When the outer IP header is IPv4, VTEPs MUST set the DF bit. 328 Outer Ethernet Header: 330 Most data centers networks are built on Ethernet. Assuming the outer 331 IP packet is being sent across Ethernet, there will be an Ethernet 332 header used to deliver the IP packet to the next hop, which could be 333 the destination VTEP or be a router used to forward the IP packet 334 towards the destination VTEP. If VLANs are in use within the data 335 center, then this Ethernet header would also contain a VLAN tag. 337 The following figures show the entire stack of protocol headers that 338 would be seen on an Ethernet link carrying encapsulated packets from 339 a VTEP across the underlay network for both IPv4 and IPv6 based 340 underlay networks. 342 0 1 2 3 343 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 345 Outer Ethernet Header: 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Outer Destination MAC Address | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Outer Destination MAC Address | Outer Source MAC Address | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Outer Source MAC Address | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Ethertype = 0x0800 | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Outer IPv4 Header: 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |Version| IHL |Type of Service| Total Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Identification |Flags| Fragment Offset | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Time to Live |Protocl=17(UDP)| Header Checksum | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Outer Source IPv4 Address | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Outer Destination IPv4 Address | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Outer UDP Header: 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Source Port | Dest Port = 4790 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | UDP Length | UDP Checksum | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 VXLAN GPE Header: 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | VXLAN Network Identifier (VNI) | Reserved | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Payload: 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Depends on VXLAN GPE Next Protocol field above. | 388 | Note that if the payload is Ethernet, then the original | 389 | Ethernet Frame's FCS is not included. | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Frame Check Sequence: 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 3: Outer Headers for VXLAN GPE over IPv4 399 0 1 2 3 400 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 402 Outer Ethernet Header: 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Outer Destination MAC Address | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Outer Destination MAC Address | Outer Source MAC Address | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Outer Source MAC Address | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Ethertype = 0x86DD | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Outer IPv6 Header: 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |Version| Traffic Class | Flow Label | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 + + 423 | | 424 + Outer Source IPv6 Address + 425 | | 426 + + 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 + + 431 | | 432 + Outer Destination IPv6 Address + 433 | | 434 + + 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Outer UDP Header: 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Source Port | Dest Port = 4790 | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | UDP Length | UDP Checksum | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 VXLAN GPE Header: 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | VXLAN Network Identifier (VNI) | Reserved | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Payload: 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Depends on VXLAN GPE Next Protocol field above. | 455 | Note that if the payload is Ethernet, then the original | 456 | Ethernet Frame's FCS is not included. | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Frame Check Sequence: 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 4: Outer Headers for VXLAN GPE over IPv6 466 4.1. Inner VLAN Tag Handling 468 If the inner packet (as indicated by the VXLAN GPE Next Protocol 469 field) is an Ethernet frame, it is recommended that it does not 470 contain a VLAN tag. In the most common scenarios, the tenant VLAN 471 tag is translated into a VXLAN Network Identifier. In these 472 scenarios, VTEPs should never send an inner Ethernet frame with a 473 VLAN tag, and a VTEP performing decapsulation should discard any 474 inner frames received with a VLAN tag. However, if the VTEPs are 475 specifically configured to support it for a specific VXLAN Network 476 Identifier, a VTEP may support transparent transport of the inner 477 VLAN tag between all tenant systems on that VNI. The VTEP never 478 looks at the value of the inner VLAN tag, but simply passes it across 479 the underlay. 481 4.2. Fragmentation Considerations 483 VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when 484 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer 485 IPv4 header. It is recommended that the underlay network be 486 configured to carry an MTU at least large enough to accommodate the 487 added encapsulation headers. It is recommended that VTEPs perform 488 Path MTU discovery [RFC1191] [RFC1981] to determine if the underlay 489 network can carry the encapsulated payload packet. 491 5. Backward Compatibility 493 5.1. VXLAN VTEP to VXLAN GPE VTEP 495 A VXLAN VTEP conforms to VXLAN frame format and uses UDP destination 496 port 4789 when sending traffic to VXLAN GPE VTEP. As per VXLAN, 497 reserved bits 5 and 7, VXLAN GPE P and O-bits respectively must be 498 set to zero. The remaining reserved bits must be zero, including the 499 VXLAN GPE version field, bits 2 and 3. The encapsulated payload MUST 500 be Ethernet. 502 5.2. VXLAN GPE VTEP to VXLAN VTEP 504 A VXLAN GPE VTEP MUST NOT encapsulate non-Ethernet frames to a VXLAN 505 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN 506 GPE VTEP MUST conform to VXLAN frame format and hence will set the P 507 bit to 0, the Next Protocol to 0 and use UDP destination port 4789. 508 A VXLAN GPE VTEP MUST also set O = 0 and Ver = 0 when encapsulating 509 Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP will treat 510 this packet as a VXLAN packet. 512 A method for determining the capabilities of a VXLAN VTEP (GPE or 513 non-GPE) is out of the scope of this draft. 515 5.3. VXLAN GPE UDP Ports 517 VXLAN GPE uses a IANA assigned UDP destination port, 4790, when 518 sending traffic to VXLAN GPE VTEPs. 520 5.4. VXLAN GPE and Encapsulated IP Header Fields 522 When encapsulating and decapsulating IPv4 and IPv6 packets, certain 523 fields, such as IPv4 Time to Live (TTL) from the inner IP header need 524 to be considered. VXLAN GPE IP encapsulation and decapsulation 525 utilizes the techniques described in [RFC6830], section 5.3. 527 6. VXLAN GPE Examples 529 This section provides three examples of protocols encapsulated using 530 the Generic Protocol Extension for VXLAN described in this document. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |R|R|0|0|I|1|R|0| Reserved | NP = IPv4 | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | VXLAN Network Identifier (VNI) | Reserved | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Original IPv4 Packet | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Figure 5: IPv4 and VXLAN GPE 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |R|R|0|0|I|1|R|0| Reserved | NP = IPv6 | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | VXLAN Network Identifier (VNI) | Reserved | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Original IPv6 Packet | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 6: IPv6 and VXLAN GPE 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |R|R|0|0|I|1|R|0| Reserved |NP = Ethernet | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | VXLAN Network Identifier (VNI) | Reserved | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Original Ethernet Frame | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 7: Ethernet and VXLAN GPE 568 7. Security Considerations 570 VXLAN's security is focused on issues around L2 encapsulation into 571 L3. With VXLAN GPE, issues such as spoofing, flooding, and traffic 572 redirection are dependent on the particular protocol payload 573 encapsulated. 575 8. Contributors 576 Paul Quinn 577 Cisco Systems 578 paulq@cisco.com 580 Rajeev Manur 581 Broadcom 582 rmanur@broadcom.com 584 Michael Smith 585 Cisco Systems 586 michsmit@cisco.com 588 Darrel Lewis 589 Cisco Systems 590 darlewis@cisco.com 592 Puneet Agarwal 593 Innovium, Inc 594 puneet@acm.org 596 Lucy Yong 597 Huawei USA 598 lucy.yong@huawei.com 600 Xiaohu Xu 601 Huawei Technologies 602 xuxiaohu@huawei.com 604 Pankaj Garg 605 Microsoft 606 pankajg@microsoft.com 608 David Melman 609 Marvell 610 davidme@marvell.com 612 9. Acknowledgments 614 A special thank you goes to Dino Farinacci for his guidance and 615 detailed review. 617 10. IANA Considerations 619 10.1. UDP Port 621 UDP 4790 port has been assigned by IANA for VXLAN GPE. 623 10.2. VXLAN GPE Next Protocol 625 IANA is requested to set up a registry of "Next Protocol". These are 626 8-bit values. Next Protocol values in the table below are defined in 627 this draft. New values are assigned via Standards Action [RFC5226]. 629 +---------------+-------------+---------------+ 630 | Next Protocol | Description | Reference | 631 +---------------+-------------+---------------+ 632 | 0 | Reserved | This Document | 633 | 1 | IPv4 | This Document | 634 | 2 | IPv6 | This Document | 635 | 3 | Ethernet | This Document | 636 | 4 | NSH | This Document | 637 | 5 | MPLS | This Document | 638 | 6 | GBP | This Document | 639 | 7 | vBNG | This Document | 640 | 8..255 | Unassigned | | 641 +---------------+-------------+---------------+ 643 10.3. VXLAN GPE Flag and Reserved Bits 645 There are ten flag bits at the beginning of the VXLAN GPE header, 646 followed by 16 reserved bits and an 8-bit reserved field at the end 647 of the header. New bits are assigned via Standards Action [RFC5226]. 649 Bits 0-1 - Reserve6 651 Bits 2-3 - Version 653 Bit 4 - Instance ID (I bit) 655 Bit 5 - Next Protocol (P bit) 657 Bit 6 - Reserved 659 Bit 7 - OAM (O bit) 661 Bit 8-23 - Reserved 663 Bits 24-31 in the 2nd Word -- Reserved 665 Reserved bits/fields MUST be set to 0 by the sender and ignored by 666 the receiver. 668 11. References 670 11.1. Normative References 672 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 673 DOI 10.17487/RFC1191, November 1990, . 676 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 677 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 678 1996, . 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, 682 DOI 10.17487/RFC2119, March 1997, . 685 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 686 Label Switching Architecture", RFC 3031, 687 DOI 10.17487/RFC3031, January 2001, . 690 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 691 IANA Considerations Section in RFCs", RFC 5226, 692 DOI 10.17487/RFC5226, May 2008, . 695 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 696 Cheshire, "Internet Assigned Numbers Authority (IANA) 697 Procedures for the Management of the Service Name and 698 Transport Protocol Port Number Registry", BCP 165, 699 RFC 6335, DOI 10.17487/RFC6335, August 2011, 700 . 702 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 703 Locator/ID Separation Protocol (LISP)", RFC 6830, 704 DOI 10.17487/RFC6830, January 2013, . 707 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 708 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 709 eXtensible Local Area Network (VXLAN): A Framework for 710 Overlaying Virtualized Layer 2 Networks over Layer 3 711 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 712 . 714 11.2. Informative References 716 [I-D.huang-nvo3-vxlan-gpe-extension-for-vbng] 717 Huang, L., Hu, S., Wang, Z., and T. Ao, "VXLAN GPE 718 Extension for Packets Exchange Between Control and User 719 Plane of vBNG", draft-huang-nvo3-vxlan-gpe-extension-for- 720 vbng-01 (work in progress), October 2017. 722 [I-D.ietf-bess-evpn-overlay] 723 Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, 724 J., and W. Henderickx, "A Network Virtualization Overlay 725 Solution using EVPN", draft-ietf-bess-evpn-overlay-08 726 (work in progress), March 2017. 728 [I-D.ietf-idr-tunnel-encaps] 729 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 730 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 731 (work in progress), July 2017. 733 [I-D.ietf-sfc-nsh] 734 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 735 Header (NSH)", draft-ietf-sfc-nsh-27 (work in progress), 736 October 2017. 738 [I-D.lemon-vxlan-gpe-gbp] 739 Lemon, J., Maino, F., and M. Smith, "Group Policy Encoding 740 with VXLAN-GPE", draft-lemon-vxlan-gpe-gbp-00 (work in 741 progress), October 2017. 743 Authors' Addresses 745 Fabio Maino (Editor) 746 Cisco Systems 748 Email: fmaino@cisco.com 750 Larry Kreeger (editor) 752 Email: lkreeger@gmail.com 754 Uri Elzur (editor) 755 Intel 757 Email: uri.elzur@intel.com