idnits 2.17.1 draft-ietf-nvo3-vxlan-gpe-04.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 (April 27, 2017) is 2556 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 (-12) exists of draft-ietf-bess-evpn-overlay-08 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-04 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 Summary: 4 errors (**), 0 flaws (~~), 4 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: October 29, 2017 6 U. Elzur, Ed. 7 Intel 8 April 27, 2017 10 Generic Protocol Extension for VXLAN 11 draft-ietf-nvo3-vxlan-gpe-04 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 October 29, 2017. 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 . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Outer Encapsulations . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Inner VLAN Tag Handling . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . 14 84 10.3. VXLAN GPE Flag and Reserved Bits . . . . . . . . . . . . 14 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 11.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 3.3. Replicated BUM Traffic 258 Flag bit 6 is defined as the B bit. When the B bit is set to 1, the 259 packet is marked as an an ingress-replicated BUM Traffic (i.e. 260 Broadcast, Unknown unicast, or Multicast) to help egress VTEP to 261 differentiate between known and unknown unicast. The details of 262 using the B bit are out of scope for this document, but please see 263 [I-D.ietf-bess-evpn-overlay] for an example in the EVPN context. As 264 with the P-bit, bit 6 is currently a reserved flag in VXLAN. 266 3.4. OAM Support 268 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 269 packet is an OAM packet and OAM processing MUST occur. Other header 270 fields including Next Protocol MUST adhere to the definitions in 271 Section 3. The OAM protocol details are out of scope for this 272 document. As with the P-bit, bit 7 is currently a reserved flag in 273 VXLAN. 275 3.5. Version Bits 277 VXLAN GPE bits 2 and 3 are defined as version bits. These bits are 278 reserved in VXLAN. The version field is used to ensure backward 279 compatibility going forward with future VXLAN GPE updates. 281 The initial version for VXLAN GPE is 0. 283 4. Outer Encapsulations 285 In addition to the VXLAN GPE header, the packet is further 286 encapsulated in UDP and IP. Data centers based on Ethernet, will 287 then send this IP packet over Ethernet. 289 Outer UDP Header: 291 Destination UDP Port: IANA has assigned the value 4790 for the VXLAN 292 GPE UDP port. This well-known destination port is used when sending 293 VXLAN GPE encapsulated packets. 295 Source UDP Port: The source UDP port is used as entropy for devices 296 forwarding encapsulated packets across the underlay (ECMP for IP 297 routers, or load splitting for link aggregation by bridges). Tenant 298 traffic flows should all use the same source UDP port to lower the 299 chances of packet reordering by the underlay for a given flow. It is 300 recommended for VTEPs to generate this port number using a hash of 301 the inner packet headers. Implementations MAY use the entire 16 bit 302 source UDP port for entropy. 304 UDP Checksum: Source VTEPs MAY either calculate a valid checksum, or 305 if this is not possible, set the checksum to zero. When calculating 306 a checksum, it MUST be calculated across the entire packet (outer IP 307 header, UDP header, VXLAN GPE header and payload packet). All 308 receiving VTEPs must accept a checksum value of zero. If the 309 receiving VTEP is capable of validating the checksum, it MAY validate 310 a non-zero checksum and MUST discard the packet if the checksum is 311 determined to be invalid. 313 Outer IP Header: 315 This is the header used by the underlay network to deliver packets 316 between VTEPs. The destination IP address can be a unicast or a 317 multicast IP address. The source IP address must be the source VTEP 318 IP address which can be used to return tenant packets to the tenant 319 system source address within the inner packet header. 321 When the outer IP header is IPv4, VTEPs MUST set the DF bit. 323 Outer Ethernet Header: 325 Most data centers networks are built on Ethernet. Assuming the outer 326 IP packet is being sent across Ethernet, there will be an Ethernet 327 header used to deliver the IP packet to the next hop, which could be 328 the destination VTEP or be a router used to forward the IP packet 329 towards the destination VTEP. If VLANs are in use within the data 330 center, then this Ethernet header would also contain a VLAN tag. 332 The following figures show the entire stack of protocol headers that 333 would be seen on an Ethernet link carrying encapsulated packets from 334 a VTEP across the underlay network for both IPv4 and IPv6 based 335 underlay networks. 337 0 1 2 3 338 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 340 Outer Ethernet Header: 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Outer Destination MAC Address | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Outer Destination MAC Address | Outer Source MAC Address | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Outer Source MAC Address | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Ethertype = 0x0800 | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Outer IPv4 Header: 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |Version| IHL |Type of Service| Total Length | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Identification |Flags| Fragment Offset | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Time to Live |Protocl=17(UDP)| Header Checksum | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Outer Source IPv4 Address | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Outer Destination IPv4 Address | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Outer UDP Header: 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Source Port | Dest Port = 4790 | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | UDP Length | UDP Checksum | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 VXLAN GPE Header: 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | VXLAN Network Identifier (VNI) | Reserved | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Payload: 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Depends on VXLAN GPE Next Protocol field above. | 383 | Note that if the payload is Ethernet, then the original | 384 | Ethernet Frame's FCS is not included. | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Frame Check Sequence: 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 3: Outer Headers for VXLAN GPE over IPv4 394 0 1 2 3 395 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 397 Outer Ethernet Header: 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Outer Destination MAC Address | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Outer Destination MAC Address | Outer Source MAC Address | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Outer Source MAC Address | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Ethertype = 0x86DD | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Outer IPv6 Header: 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |Version| Traffic Class | Flow Label | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 + + 418 | | 419 + Outer Source IPv6 Address + 420 | | 421 + + 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 + + 426 | | 427 + Outer Destination IPv6 Address + 428 | | 429 + + 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Outer UDP Header: 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Source Port | Dest Port = 4790 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | UDP Length | UDP Checksum | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 VXLAN GPE Header: 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |R|R|Ver|I|P|R|O| Reserved |Next Protocol | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | VXLAN Network Identifier (VNI) | Reserved | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Payload: 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Depends on VXLAN GPE Next Protocol field above. | 450 | Note that if the payload is Ethernet, then the original | 451 | Ethernet Frame's FCS is not included. | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Frame Check Sequence: 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 4: Outer Headers for VXLAN GPE over IPv6 461 4.1. Inner VLAN Tag Handling 463 If the inner packet (as indicated by the VXLAN GPE Next Protocol 464 field) is an Ethernet frame, it is recommended that it does not 465 contain a VLAN tag. In the most common scenarios, the tenant VLAN 466 tag is translated into a VXLAN Network Identifier. In these 467 scenarios, VTEPs should never send an inner Ethernet frame with a 468 VLAN tag, and a VTEP performing decapsulation should discard any 469 inner frames received with a VLAN tag. However, if the VTEPs are 470 specifically configured to support it for a specific VXLAN Network 471 Identifier, a VTEP may support transparent transport of the inner 472 VLAN tag between all tenant systems on that VNI. The VTEP never 473 looks at the value of the inner VLAN tag, but simply passes it across 474 the underlay. 476 4.2. Fragmentation Considerations 478 VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when 479 the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer 480 IPv4 header. It is recommended that the underlay network be 481 configured to carry an MTU at least large enough to accommodate the 482 added encapsulation headers. It is recommended that VTEPs perform 483 Path MTU discovery [RFC1191] [RFC1981] to determine if the underlay 484 network can carry the encapsulated payload packet. 486 5. Backward Compatibility 488 5.1. VXLAN VTEP to VXLAN GPE VTEP 490 A VXLAN VTEP conforms to VXLAN frame format and uses UDP destination 491 port 4789 when sending traffic to VXLAN GPE VTEP. As per VXLAN, 492 reserved bits 5 and 7, VXLAN GPE P and O-bits respectively must be 493 set to zero. The remaining reserved bits must be zero, including the 494 VXLAN GPE version field, bits 2 and 3. The encapsulated payload MUST 495 be Ethernet. 497 5.2. VXLAN GPE VTEP to VXLAN VTEP 499 A VXLAN GPE VTEP MUST NOT encapsulate non-Ethernet frames to a VXLAN 500 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN 501 GPE VTEP MUST conform to VXLAN frame format and hence will set the P 502 bit to 0, the Next Protocol to 0 and use UDP destination port 4789. 503 A VXLAN GPE VTEP MUST also set O = 0 and Ver = 0 when encapsulating 504 Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP will treat 505 this packet as a VXLAN packet. 507 A method for determining the capabilities of a VXLAN VTEP (GPE or 508 non-GPE) is out of the scope of this draft. 510 5.3. VXLAN GPE UDP Ports 512 VXLAN GPE uses a IANA assigned UDP destination port, 4790, when 513 sending traffic to VXLAN GPE VTEPs. 515 5.4. VXLAN GPE and Encapsulated IP Header Fields 517 When encapsulating and decapsulating IPv4 and IPv6 packets, certain 518 fields, such as IPv4 Time to Live (TTL) from the inner IP header need 519 to be considered. VXLAN GPE IP encapsulation and decapsulation 520 utilizes the techniques described in [RFC6830], section 5.3. 522 6. VXLAN GPE Examples 524 This section provides three examples of protocols encapsulated using 525 the Generic Protocol Extension for VXLAN described in this document. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 |R|R|0|0|I|1|R|0| Reserved | NP = IPv4 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | VXLAN Network Identifier (VNI) | Reserved | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Original IPv4 Packet | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 5: IPv4 and VXLAN GPE 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |R|R|0|0|I|1|R|0| Reserved | NP = IPv6 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | VXLAN Network Identifier (VNI) | Reserved | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Original IPv6 Packet | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 6: IPv6 and VXLAN GPE 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |R|R|0|0|I|1|R|0| Reserved |NP = Ethernet | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | VXLAN Network Identifier (VNI) | Reserved | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Original Ethernet Frame | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Figure 7: Ethernet and VXLAN GPE 563 7. Security Considerations 565 VXLAN's security is focused on issues around L2 encapsulation into 566 L3. With VXLAN GPE, issues such as spoofing, flooding, and traffic 567 redirection are dependent on the particular protocol payload 568 encapsulated. 570 8. Contributors 572 Paul Quinn 573 Cisco Systems 574 paulq@cisco.com 576 Rajeev Manur 577 Broadcom 578 rmanur@broadcom.com 580 Michael Smith 581 Cisco Systems 582 michsmit@cisco.com 584 Darrel Lewis 585 Cisco Systems 586 darlewis@cisco.com 588 Puneet Agarwal 589 Innovium, Inc 590 puneet@acm.org 592 Lucy Yong 593 Huawei USA 594 lucy.yong@huawei.com 596 Xiaohu Xu 597 Huawei Technologies 598 xuxiaohu@huawei.com 600 Pankaj Garg 601 Microsoft 602 pankajg@microsoft.com 604 David Melman 605 Marvell 606 davidme@marvell.com 608 9. Acknowledgments 610 A special thank you goes to Dino Farinacci for his guidance and 611 detailed review. 613 10. IANA Considerations 615 10.1. UDP Port 617 UDP 4790 port has been assigned by IANA for VXLAN GPE. 619 10.2. VXLAN GPE Next Protocol 621 IANA is requested to set up a registry of "Next Protocol". These are 622 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in 623 this draft. New values are assigned via Standards Action [RFC5226]. 625 +---------------+-------------+---------------+ 626 | Next Protocol | Description | Reference | 627 +---------------+-------------+---------------+ 628 | 0 | Reserved | This Document | 629 | 1 | IPv4 | This Document | 630 | 2 | IPv6 | This Document | 631 | 3 | Ethernet | This Document | 632 | 4 | NSH | This Document | 633 | 5 | MPLS | This Document | 634 | 6..253 | Unassigned | | 635 +---------------+-------------+---------------+ 637 10.3. VXLAN GPE Flag and Reserved Bits 639 There are ten flag bits at the beginning of the VXLAN GPE header, 640 followed by 16 reserved bits and an 8-bit reserved field at the end 641 of the header. New bits are assigned via Standards Action [RFC5226]. 643 Bits 0-1 - Reserved 645 Bits 2-3 - Version 647 Bit 4 - Instance ID (I bit) 649 Bit 5 - Next Protocol (P bit) 651 Bit 6 - Reserved 653 Bit 7 - OAM (O bit) 655 Bit 8-23 - Reserved 656 Bits 24-31 in the 2nd Word -- Reserved 658 Reserved bits/fields MUST be set to 0 by the sender and ignored by 659 the receiver. 661 11. References 663 11.1. Normative References 665 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 666 DOI 10.17487/RFC1191, November 1990, 667 . 669 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 670 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 671 1996, . 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 679 Label Switching Architecture", RFC 3031, 680 DOI 10.17487/RFC3031, January 2001, 681 . 683 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 684 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 685 DOI 10.17487/RFC5226, May 2008, 686 . 688 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 689 Cheshire, "Internet Assigned Numbers Authority (IANA) 690 Procedures for the Management of the Service Name and 691 Transport Protocol Port Number Registry", BCP 165, 692 RFC 6335, DOI 10.17487/RFC6335, August 2011, 693 . 695 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 696 Locator/ID Separation Protocol (LISP)", RFC 6830, 697 DOI 10.17487/RFC6830, January 2013, 698 . 700 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 701 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 702 eXtensible Local Area Network (VXLAN): A Framework for 703 Overlaying Virtualized Layer 2 Networks over Layer 3 704 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 705 . 707 11.2. Informative References 709 [I-D.ietf-bess-evpn-overlay] 710 Sajassi, A., Drake, J., Bitar, N., Shekhar, R., Uttaro, 711 J., and W. Henderickx, "A Network Virtualization Overlay 712 Solution using EVPN", draft-ietf-bess-evpn-overlay-08 713 (work in progress), March 2017. 715 [I-D.ietf-idr-tunnel-encaps] 716 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 717 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-04 718 (work in progress), April 2017. 720 [I-D.ietf-sfc-nsh] 721 Quinn, P. and U. Elzur, "Network Service Header", draft- 722 ietf-sfc-nsh-12 (work in progress), February 2017. 724 Authors' Addresses 726 Fabio Maino (Editor) 727 Cisco Systems 729 Email: fmaino@cisco.com 731 Larry Kreeger (editor) 733 Email: lkreeger@gmail.com 735 Uri Elzur (editor) 736 Intel 738 Email: uri.elzur@intel.com