idnits 2.17.1 draft-mahalingam-dutt-dcops-vxlan-09.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 10, 2014) is 3640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Mahalingam 3 Internet Draft Storvisor 4 Intended Status: Informational D. Dutt 5 Expires: October 10, 2014 Cumulus Networks 6 K. Duda 7 Arista 8 P. Agarwal 9 Broadcom 10 L. Kreeger 11 Cisco 12 T. Sridhar 13 VMware 14 M. Bursell 15 Citrix 16 C. Wright 17 Red Hat 18 April 10, 2014 20 VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over 21 Layer 3 Networks 22 draft-mahalingam-dutt-dcops-vxlan-09.txt 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on October 10, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. 59 Abstract 61 This document describes Virtual eXtensible Local Area Network 62 (VXLAN), which is used to address the need for overlay networks 63 within virtualized data centers accommodating multiple tenants. The 64 scheme and the related protocols can be used in cloud service 65 provider and enterprise data center networks. This memo documents the 66 deployed VXLAN protocol for the benefit of the IETF community. 68 Table of Contents 70 1. Introduction...................................................3 71 1.1. Acronyms & Definitions....................................4 72 2. Conventions used in this document..............................5 73 3. VXLAN Problem Statement........................................5 74 3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5 75 3.2. Multitenant Environments..................................6 76 3.3. Inadequate Table Sizes at ToR Switch......................6 77 4. Virtual eXtensible Local Area Network (VXLAN)..................7 78 4.1. Unicast VM to VM communication............................8 79 4.2. Broadcast Communication and Mapping to Multicast..........9 80 4.3. Physical Infrastructure Requirements.....................10 81 5. VXLAN Frame Format............................................10 82 6. VXLAN Deployment Scenarios....................................16 83 6.1. Inner VLAN Tag Handling..................................19 84 7. Security Considerations.......................................19 85 8. IANA Considerations...........................................21 86 9. References....................................................21 87 9.1. Normative References.....................................21 88 9.2. Informative References...................................21 89 10. Acknowledgments..............................................22 91 1. Introduction 93 Server virtualization has placed increased demands on the physical 94 network infrastructure. A physical server now has multiple virtual 95 machines (VMs) each with its own MAC address. This requires larger 96 MAC address tables in the switched Ethernet network due to potential 97 attachment of and communication among hundreds of thousands of VMs. 99 In the case when the VMs in a data center are grouped according to 100 their Virtual LAN (VLAN, one might need thousands of VLANs to 101 partition the traffic according to the specific group that the VM 102 may belong to. The current VLAN limit of 4094 is inadequate in such 103 situations. 105 Data centers are often required to host multiple tenants, each with 106 their own isolated network domain. Since it is not economical to 107 realize this with dedicated infrastructure, network administrators 108 opt to implement isolation over a shared network. In such scenarios, 109 a common problem is that each tenant may independently assign MAC 110 addresses and VLAN IDs leading to potential duplication of these on 111 the physical network. 113 An important requirement for virtualized environments using a Layer 114 2 physical infrastructure is having the Layer 2 network scale across 115 the entire data center or even between data centers for efficient 116 allocation of compute, network and storage resources. In such 117 networks, using traditional approaches like the Spanning Tree 118 Protocol (STP) for a loop free topology can result in a large number 119 of disabled links. 121 The last scenario is the case where the network operator prefers to 122 use IP for interconnection of the physical infrastructure (e.g. to 123 achieve multipath scalability through Equal Cost Multipath (ECMP), 124 thus avoiding disabled links). Even in such environments, there is a 125 need to preserve the Layer 2 model for inter-VM communication. 127 The scenarios described above lead to a requirement for an overlay 128 network. This overlay is used to carry the MAC traffic from the 129 individual VMs in an encapsulated format over a logical "tunnel". 131 This document details a framework termed Virtual eXtensible Local 132 Area Network (VXLAN) which provides such an encapsulation scheme to 133 address the various requirements specified above. This memo 134 documents the deployed VXLAN protocol for the benefit of the IETF 135 community. 137 1.1. Acronyms & Definitions 139 ACL - Access Control List 141 ECMP - Equal Cost Multipath 143 IGMP - Internet Group Management Protocol 145 MTU - Maximum Transmission Unit 147 PIM - Protocol Independent Multicast 149 SPB - Shortest Path Bridging 151 STP - Spanning Tree Protocol 153 ToR - Top of Rack 155 TRILL - Transparent Interconnection of Lots of Links 157 VXLAN - Virtual eXtensible Local Area Network 159 VXLAN Segment - VXLAN Layer 2 overlay network over which VMs 161 communicate 163 VXLAN Overlay Network - VXLAN Segment 165 VXLAN Gateway - an entity which forwards traffic between VXLAN 167 and non-VXLAN environments 169 VTEP - VXLAN Tunnel End Point - an entity which originates 170 and/or terminates VXLAN tunnels 172 VLAN - Virtual Local Area Network 173 VM - Virtual Machine 175 VNI - VXLAN Network Identifier (or VXLAN Segment ID) 177 2. Conventions used in this document 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC-2119 [RFC2119]. 183 3. VXLAN Problem Statement 185 This section provides further details on the areas that VXLAN is 186 intended to address. The focus is on the networking infrastructure 187 within the data center and the issues related to them. 189 3.1. Limitations imposed by Spanning Tree & VLAN Ranges 191 Current Layer 2 networks use the IEEE 802.1D Spanning Tree Protocol 192 (STP) [802.1D] to avoid loops in the network due to duplicate paths. 193 STP blocks the use of links to avoid the replication and looping of 194 frames. Some data center operators see this as a problem with Layer 195 2 networks in general since with STP they are effectively paying for 196 more ports and links than they can really use. In addition, 197 resiliency due to multipathing is not available with the STP model. 198 Newer initiatives such as TRILL [RFC6325] and SPB[802.1aq]) have 199 been proposed to help with multipathing and thus surmount some of 200 the problems with STP. STP limitations may also be avoided by 201 configuring servers within a rack to be on the same Layer 3 network 202 with switching happening at Layer 3 both within the rack and between 203 racks. However, this is incompatible with a Layer 2 model for inter- 204 VM communication. 206 A key characteristic of Layer 2 data center networks is their use of 207 Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit VLAN 208 ID is used in the Ethernet data frames to divide the larger Layer 2 209 network into multiple broadcast domains. This has served well for 210 several data centers which require fewer than 4094 VLANs. With the 211 growing adoption of virtualization, this upper limit is seeing 212 pressure. Moreover, due to STP, several data centers limit the 213 number of VLANs that could be used. In addition, requirements for 214 multitenant environments accelerate the need for larger VLAN limits, 215 as discussed in Section 3.3. 217 3.2. Multitenant Environments 219 Cloud computing involves on demand elastic provisioning of resources 220 for multi-tenant environments. The most common example of cloud 221 computing is the public cloud, where a cloud service provider offers 222 these elastic services to multiple customers/tenants over the same 223 physical infrastructure. 225 Isolation of network traffic by tenant could be done via Layer 2 or 226 Layer 3 networks. For Layer 2 networks, VLANs are often used to 227 segregate traffic - so a tenant could be identified by its own VLAN, 228 for example. Due to the large number of tenants that a cloud 229 provider might service, the 4094 VLAN limit is often inadequate. In 230 addition, there is often a need for multiple VLANs per tenant, which 231 exacerbates the issue. 233 A related use case is cross pod expansion. A pod typically consists 234 of one or more racks of servers with associated network and storage 235 connectivity. Tenants may start off on a pod and, due to expansion, 236 require servers/VMs on other pods, especially in the case when 237 tenants on the other pods are not fully utilizing all their 238 resources. This use case requires a "stretched" Layer 2 environment 239 connecting the individual servers/VMs. 241 Layer 3 networks are not a comprehensive solution for multi tenancy 242 either. Two tenants might use the same set of Layer 3 addresses 243 within their networks which requires the cloud provider to provide 244 isolation in some other form. Further, requiring all tenants to use 245 IP excludes customers relying on direct Layer 2 or non-IP Layer 3 246 protocols for inter VM communication. 248 3.3. Inadequate Table Sizes at ToR Switch 250 Today's virtualized environments place additional demands on the MAC 251 address tables of Top of Rack (ToR) switches which connect to the 252 servers. Instead of just one MAC address per server link, the ToR 253 now has to learn the MAC addresses of the individual VMs (which 254 could range in the 100s per server). This is needed because traffic 255 from/to the VMs to the rest of the physical network will traverse 256 the link between the server and the switch. A typical ToR switch 257 could connect to 24 or 48 servers depending upon the number of its 258 server facing ports. A data center might consist of several racks, 259 so each ToR switch would need to maintain an address table for the 260 communicating VMs across the various physical servers. This places a 261 much larger demand on the table capacity compared to non-virtualized 262 environments. 264 If the table overflows, the switch may stop learning new addresses 265 until idle entries age out, leading to significant flooding of 266 subsequent unknown destination frames. 268 4. Virtual eXtensible Local Area Network (VXLAN) 270 VXLAN (Virtual eXtensible Local Area Network) addresses the above 271 requirements of the Layer 2 and Layer 3 data center network 272 infrastructure in the presence of VMs in a multi-tenant environment. 273 It runs over the existing networking infrastructure and provides a 274 means to "stretch" a Layer 2 network. In short, VXLAN is a Layer 2 275 overlay scheme over a Layer 3 network. Each overlay is termed a 276 VXLAN segment. Only VMs within the same VXLAN segment can 277 communicate with each other. Each VXLAN segment is identified 278 through a 24 bit segment ID, hereafter termed the VXLAN Network 279 Identifier (VNI). This allows up to 16M VXLAN segments to coexist 280 within the same administrative domain. 282 The VNI identifies the scope of the inner MAC frame originated by 283 the individual VM. Thus, you could have overlapping MAC addresses 284 across segments but never have traffic "cross over" since the 285 traffic is isolated using the VNI. The VNI is in an outer header 286 which encapsulates the inner MAC frame originated by the VM. In the 287 following sections, the term "VXLAN segment" is used interchangeably 288 with the term "VXLAN overlay network". 290 Due to this encapsulation, VXLAN could also be termed a tunneling 291 scheme to overlay Layer 2 networks on top of Layer 3 networks. The 292 tunnels are stateless, so each frame is encapsulated according to a 293 set of rules. The end point of the tunnel (VXLAN Tunnel End Point or 294 VTEP) discussed in the following sections is located within the 295 hypervisor on the server which hosts the VM. Thus, the VNI and VXLAN 296 related tunnel/outer header encapsulation are known only to the VTEP 297 - the VM never sees it (see Figure 1). Note that it is possible that 298 VTEPs could also be on a physical switch or physical server and 299 could be implemented in software or hardware. One use case where 300 the VTEP is a physical switch is discussed in Section 6 on VXLAN 301 deployment scenarios. 303 The following sections discuss typical traffic flow scenarios in a 304 VXLAN environment using one type of control scheme - data plane 305 learning. Here, the association of VM's MAC to VTEP's IP address is 306 discovered via source address learning. Multicast is used for 307 carrying unknown destination, broadcast and multicast frames. 309 In addition to a learning based control plane, there are other 310 schemes possible for the distribution of the VTEP IP to VM MAC 311 mapping information. Options could include a central 312 authority/directory based lookup by the individual VTEPs, 313 distribution of this mapping information to the VTEPs by the central 314 authority, and so on. These are sometimes characterized as push and 315 pull models respectively. This draft will focus on the data plane 316 learning scheme as the control plane for VXLAN. 318 4.1. Unicast VM to VM communication 320 Consider a VM within a VXLAN overlay network. This VM is unaware of 321 VXLAN. To communicate with a VM on a different host, it sends a MAC 322 frame destined to the target as normal. The VTEP on the physical 323 host looks up the VNI to which this VM is associated. It then 324 determines if the destination MAC is on the same segment and if 325 there is a mapping of the destination MAC address to 326 the remote VTEP. If so, an outer header comprising an outer MAC, 327 outer IP header and VXLAN header (see Figure 1 in Section 5 for 328 frame format) are prepended to the original MAC frame. The 329 encapsulated packet is forwarded towards the remote VTEP. Upon 330 reception, the remote VTEP verifies the validity of the VNI and if 331 there is a VM on that VNI using a MAC address that matches the inner 332 destination MAC address. If so, the packet is stripped of its 333 encapsulating headers and passed on to the destination VM. The 334 destination VM never knows about the VNI or that the frame was 335 transported with a VXLAN encapsulation. 337 In addition to forwarding the packet to the destination VM, the 338 remote VTEP learns the Inner Source MAC to outer Source IP address 339 mapping. It stores this mapping in a table so that when the 340 destination VM sends a response packet, there is no need for an 341 "unknown destination" flooding of the response packet. 343 Determining the MAC address of the destination VM prior to the 344 transmission by the source VM is performed as with non-VXLAN 345 environments except as described in Section 4.2. Broadcast frames 346 are used but are encapsulated within a multicast packet, as detailed 347 in the Section 4.2. 349 4.2. Broadcast Communication and Mapping to Multicast 351 Consider the VM on the source host attempting to communicate with 352 the destination VM using IP. Assuming that they are both on the 353 same subnet, the VM sends out an ARP broadcast frame. In the non- 354 VXLAN environment, this frame would be sent out using MAC broadcast 355 across all switches carrying that VLAN. 357 With VXLAN, a header including the VXLAN VNI is inserted at the 358 beginning of the packet along with the IP header and UDP header. 359 However, this broadcast packet is sent out to the IP multicast group 360 on which that VXLAN overlay network is realized. 362 To effect this, we need to have a mapping between the VXLAN VNI and 363 the IP multicast group that it will use. This mapping is done at the 364 management layer and provided to the individual VTEPs through a 365 management channel. Using this mapping, the VTEP can provide IGMP 366 membership reports to the upstream switch/router to join/leave the 367 VXLAN related IP multicast groups as needed. This will enable 368 pruning of the leaf nodes for specific multicast traffic addresses 369 based on whether a member is available on this host using the 370 specific multicast address (see [RFC4541]). In addition, use of 371 multicast routing protocols like Protocol Independent Multicast - 372 Sparse Mode (PIM-SM see [RFC4601]) will provide efficient multicast 373 trees within the Layer 3 network. 375 The VTEP will use (*,G) joins. This is needed as the set of VXLAN 376 tunnel sources is unknown and may change often, as the VMs come 377 up/go down across different hosts. A side note here is that since 378 each VTEP can act as both the source and destination for multicast 379 packets, a protocol like PIM-bidir (see [RFC5015]) would be more 380 efficient. 382 The destination VM sends a standard ARP response using IP unicast. 383 This frame will be encapsulated back to the VTEP connecting the 384 originating VM using IP unicast VXLAN encapsulation. This is 385 possible since the mapping of the ARP response's destination MAC to 386 the VXLAN tunnel end point IP was learned earlier through the ARP 387 request. 389 Note that multicast frames and "unknown MAC destination" frames are 390 also sent using the multicast tree, similar to the broadcast frames. 392 4.3. Physical Infrastructure Requirements 394 When IP multicast is used within the network infrastructure, a 395 multicast routing protocol like PIM-SM can be used by the individual 396 Layer 3 IP routers/switches within the network. This is used to 397 build efficient multicast forwarding trees so that multicast frames 398 are only sent to those hosts which have requested to receive them. 400 Similarly, there is no requirement that the actual network 401 connecting the source VM and destination VM should be a Layer 3 402 network - VXLAN can also work over Layer 2 networks. In either case, 403 efficient multicast replication within the Layer 2 network can be 404 achieved using IGMP snooping. 406 VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may 407 fragment encapsulated VXLAN packets due to the larger frame size. 408 The destination VTEP MAY silently discard such VXLAN fragments. To 409 ensure end to end traffic delivery without fragmentation, it is 410 RECOMMENDED that the MTUs (Maximum Transmission Units) across the 411 physical network infrastructure be set to a value that accommodates 412 the larger frame size due to the encapsulation. Other techniques 413 like Path MTU discovery (see [RFC1191] and [RFC1981]) MAY be used to 414 address this requirement as well. 416 5. VXLAN Frame Format 418 The VXLAN frame format is shown below. Parsing this from the bottom 419 of the frame - above the outer frame check sequence (FCS), there is 420 an inner MAC frame with its own Ethernet header with source, 421 destination MAC addresses along with the Ethernet type plus an 422 optional VLAN. See Section 6 for further details of inner VLAN tag 423 handling. 425 The inner MAC frame is encapsulated with the following four headers 426 (starting from the innermost header): 428 O VXLAN Header: This is an 8 byte field which has: 430 o Flags (8 bits)- where the I flag MUST be set to 1 for a valid 431 VXLAN Network ID (VNI). The other 7 bits (designated "R") are 432 reserved fields and MUST be set to zero on transmit and ignored on 433 receive. 435 o VXLAN Segment ID/VXLAN Network Identifier (VNI) - this is a 24 436 bit value used to designate the individual VXLAN overlay network 437 on which the communicating VMs are situated. VMs in different 438 VXLAN overlay networks cannot communicate with each other. 440 o Reserved fields (24 bits and 8 bits) - MUST be set to zero on 441 transmit and ignored on receive. 443 O Outer UDP Header: This is the outer UDP header with a source 444 port provided by the VTEP and the destination port being a well- 445 known UDP port. IANA has assigned the value 4789 for the VXLAN UDP 446 port and this value SHOULD be used by default as the destination UDP 447 port. Some early implementations of VXLAN have used other values 448 for the destination port. To enable interoperability with these 449 implementations, the destination port SHOULD be configurable. It is 450 recommended that the UDP source port number be calculated using a 451 hash of fields from the inner packet - one example being a hash of 452 the inner Ethernet frame`s headers. This is to enable a level of 453 entropy for ECMP/load balancing of the VM to VM traffic across the 454 VXLAN overlay. When calculating the UDP source port number in this 455 manner, it is RECOMMENDED that the value be in the dynamic/private 456 port range 49152-65535 [RFC6335]. 458 The UDP checksum field SHOULD be transmitted as zero. When a packet 459 is received with a UDP checksum of zero, it MUST be accepted for 460 decapsulation. Optionally, if the encapsulating endpoint includes a 461 non-zero UDP checksum, it MUST be correctly calculated across the 462 entire packet including the IP header, UDP header, VXLAN header and 463 encapsulated MAC frame. When a decapsulating endpoint receives a 464 packet with a non-zero checksum it MAY choose to verify the checksum 465 value. If it chooses to perform such verification, and the 466 verification fails, the packet MUST be dropped. If the 467 decapsulating destination chooses not to perform the verification, 468 or performs it successfully, the packet MUST be accepted for 469 decapsulation. 471 O Outer IP Header: This is the outer IP header with the source IP 472 address indicating the IP address of the VTEP over which the 473 communicating VM (as represented by the inner source MAC address) is 474 running. The destination IP address can be a unicast or multicast 475 IP address (see Sections 4.1 and 4.2). When it is a unicast IP 476 address, it represents the IP address of the VTEP connecting the 477 communicating VM as represented by the inner destination MAC 478 address. For multicast destination IP addresses, please refer to the 479 scenarios detailed in Section 4.2. 481 O Outer Ethernet Header (example): Figure 1 is an example of an 482 inner Ethernet frame encapsulated within an outer Ethernet + IP + 483 UDP + VXLAN header. The outer destination MAC address in this frame 484 may be the address of the target VTEP or of an intermediate Layer 3 485 router. The outer VLAN tag is optional. If present, it may be used 486 for delineating VXLAN traffic on the LAN. 488 0 1 2 3 489 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 491 Outer Ethernet Header: 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Outer Destination MAC Address | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Outer Destination MAC Address | Outer Source MAC Address | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Outer Source MAC Address | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |OptnlEthtype = C-Tag 802.1Q | Outer.VLAN Tag Information | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Ethertype = 0x0800 | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Outer IPv4 Header: 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |Version| IHL |Type of Service| Total Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Identification |Flags| Fragment Offset | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Time to Live |Protocl=17(UDP)| Header Checksum | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Outer Source IPv4 Address | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Outer Destination IPv4 Address | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Outer UDP Header: 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Source Port = xxxx | Dest Port = VXLAN Port | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | UDP Length | UDP Checksum | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 VXLAN Header: 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |R|R|R|R|I|R|R|R| Reserved | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | VXLAN Network Identifier (VNI) | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Inner Ethernet Header: 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Inner Destination MAC Address | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Inner Destination MAC Address | Inner Source MAC Address | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Inner Source MAC Address | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |OptnlEthtype = C-Tag 802.1Q | Inner.VLAN Tag Information | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Payload: 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Ethertype of Original Payload | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 547 | Original Ethernet Payload | 548 | | 549 |(Note that the original Ethernet Frame's FCS is not included) | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Frame Check Sequence: 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 1 VXLAN Frame Format with IPv4 Outer Header 559 The frame format above shows tunneling of Ethernet frames using IPv4 560 for transport. Use of VXLAN with IPv6 transport is detailed below. 562 0 1 2 3 563 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 565 Outer Ethernet Header: 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Outer Destination MAC Address | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Outer Destination MAC Address | Outer Source MAC Address | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Outer Source MAC Address | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |OptnlEthtype = C-Tag 802.1Q | Outer.VLAN Tag Information | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Ethertype = 0x86DD | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Outer IPv6 Header: 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 |Version| Traffic Class | Flow Label | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | | 585 + + 586 | | 587 + Outer Source IPv6 Address + 588 | | 589 + + 590 | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 + + 594 | | 595 + Outer Destination IPv6 Address + 596 | | 597 + + 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Outer UDP Header: 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Source Port = xxxx | Dest Port = VXLAN Port | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | UDP Length | UDP Checksum | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 VXLAN Header: 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 |R|R|R|R|I|R|R|R| Reserved | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | VXLAN Network Identifier (VNI) | Reserved | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Inner Ethernet Header: 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Inner Destination MAC Address | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Inner Destination MAC Address | Inner Source MAC Address | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Inner Source MAC Address | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 |OptnlEthtype = C-Tag 802.1Q | Inner.VLAN Tag Information | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Payload: 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Ethertype of Original Payload | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 630 | Original Ethernet Payload | 631 | | 632 |(Note that the original Ethernet Frame's FCS is not included) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Frame Check Sequence: 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Figure 2 VXLAN Frame Format with IPv6 Outer Header 642 6. VXLAN Deployment Scenarios 644 VXLAN is typically deployed in data centers on virtualized hosts, 645 which may be spread across multiple racks. The individual racks may 646 be parts of a different Layer 3 network or they could be in a single 647 Layer 2 network. The VXLAN segments/overlay networks are overlaid on 648 top of these Layer 2 or Layer 3 networks. 650 Consider Figure 3 below depicting two virtualized servers attached 651 to a Layer 3 infrastructure. The servers could be on the same rack, 652 or on different racks or potentially across data centers within the 653 same administrative domain. There are 4 VXLAN overlay networks 654 identified by the VNIs 22, 34, 74 and 98. Consider the case of VM1-1 655 in Server 1 and VM2-4 on Server 2 which are on the same VXLAN 656 overlay network identified by VNI 22. The VMs do not know about the 657 overlay networks and transport method since the encapsulation and 658 decapsulation happen transparently at the VTEPs on Servers 1 and 2. 659 The other overlay networks and the corresponding VMs are: VM1-2 on 660 Server 1 and VM2-1 on Server 2 both on VNI 34, VM1-3 on Server 1 and 661 VM2-2 on Server 2 on VNI 74, and finally VM1-4 on Server 1 and VM2-3 662 on Server 2 on VNI 98. 664 +------------+-------------+ 665 | Server 1 | 666 | +----+----+ +----+----+ | 667 | |VM1-1 | |VM1-2 | | 668 | |VNI 22 | |VNI 34 | | 669 | | | | | | 670 | +---------+ +---------+ | 671 | | 672 | +----+----+ +----+----+ | 673 | |VM1-3 | |VM1-4 | | 674 | |VNI 74 | |VNI 98 | | 675 | | | | | | 676 | +---------+ +---------+ | 677 | Hypervisor VTEP (IP1) | 678 +--------------------------+ 679 | 680 | 681 | 682 | +-------------+ 683 | | Layer 3 | 684 |---| Network | 685 | | 686 +-------------+ 687 | 688 | 689 +-----------+ 690 | 691 | 692 +------------+-------------+ 693 | Server 2 | 694 | +----+----+ +----+----+ | 695 | |VM2-1 | |VM2-2 | | 696 | |VNI 34 | |VNI 74 | | 697 | | | | | | 698 | +---------+ +---------+ | 699 | | 700 | +----+----+ +----+----+ | 701 | |VM2-3 | |VM2-4 | | 702 | |VNI 98 | |VNI 22 | | 703 | | | | | | 704 | +---------+ +---------+ | 705 | Hypervisor VTEP (IP2) | 706 +--------------------------+ 708 Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network 710 One deployment scenario is where the tunnel termination point is a 711 physical server which understands VXLAN. An alternate scenario is 712 where nodes on a VXLAN overlay network need to communicate with 713 nodes on legacy networks which could be VLAN based. These nodes may 714 be physical nodes or virtual machines. To enable this communication, 715 a network can include VXLAN gateways (see Figure 4 below with a 716 switch acting as a VXLAN gateway) which forward traffic between 717 VXLAN and non-VXLAN environments. 719 Consider Figure 4 for the following discussion. For incoming frames 720 on the VXLAN connected interface, the gateway strips out the VXLAN 721 header and forwards to a physical port based on the destination MAC 722 address of the inner Ethernet frame. Decapsulated frames with the 723 inner VLAN ID SHOULD be discarded unless configured explicitly to be 724 passed on to the non-VXLAN interface. In the reverse direction, 725 incoming frames for the non-VXLAN interfaces are mapped to a 726 specific VXLAN overlay network based on the VLAN ID in the frame. 727 Unless configured explicitly to be passed on in the encapsulated 728 VXLAN frame, this VLAN ID is removed before the frame is 729 encapsulated for VXLAN. 731 These gateways which provide VXLAN tunnel termination functions 732 could be ToR/access switches or switches higher up in the data 733 center network topology - e.g. core or even WAN edge devices. The 734 last case (WAN edge) could involve a Provider Edge (PE) router which 735 terminates VXLAN tunnels in a hybrid cloud environment. Note that in 736 all these instances, the gateway functionality could be implemented 737 in software or hardware. 739 +---+-----+---+ +---+-----+---+ 740 | Server 1 | | Non VXLAN | 741 (VXLAN enabled)<-----+ +---->| server | 742 +-------------+ | | +-------------+ 743 | | 744 +---+-----+---+ | | +---+-----+---+ 745 |Server 2 | | | | Non VXLAN | 746 (VXLAN enabled)<-----+ +---+-----+---+ +---->| server | 747 +-------------+ | |Switch acting| | +-------------+ 748 |---| as VXLAN |-----| 749 +---+-----+---+ | | Gateway | 750 | Server 3 | | +-------------+ 751 (VXLAN enabled)<-----+ 752 +-------------+ | 753 | 754 +---+-----+---+ | 755 | Server 4 | | 756 (VXLAN enabled)<-----+ 757 +-------------+ 758 Figure 4 VXLAN Deployment - VXLAN Gateway 760 6.1. Inner VLAN Tag Handling 762 Inner VLAN Tag Handling in VTEP and VXLAN Gateway should conform to 763 the following: 765 Decapsulated VXLAN frames with the inner VLAN tag SHOULD be 766 discarded unless configured otherwise. On the encapsulation side, a 767 VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless 768 configured otherwise. When a VLAN-tagged packet is a candidate for 769 VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag 770 unless configured otherwise. 772 7. Security Considerations 774 Traditionally, layer 2 networks can only be attacked from 'within' 775 by rogue endpoints - either by having inappropriate access to a LAN 776 and snooping on traffic or by injecting spoofed packets to 'take 777 over' another MAC address or by flooding and causing denial of 778 service. A MAC-over-IP mechanism for delivering Layer 2 traffic 779 significantly extends this attack surface. This can happen by rogues 780 injecting themselves into the network by subscribing to one or more 781 multicast groups that carry broadcast traffic for VXLAN segments and 782 also by sourcing MAC-over-UDP frames into the transport network to 783 inject spurious traffic, possibly to hijack MAC addresses. 785 This document does not, at this time, incorporate specific measures 786 against such attacks, relying instead on other traditional 787 mechanisms layered on top of IP. This section, instead, sketches out 788 some possible approaches to security in the VXLAN environment. 790 Traditional Layer 2 attacks by rogue end points can be mitigated by 791 limiting the management and administrative scope of who deploys and 792 manages VMs/gateways in a VXLAN environment. In addition, such 793 administrative measures may be augmented by schemes like 802.1X for 794 admission control of individual end points. Also, the use of the 795 UDP based encapsulation of VXLAN enables configuration and use of 796 the 5 tuple based ACLs (Access Control Lists) functionality in 797 physical switches. 799 Tunneled traffic over the IP network can be secured with traditional 800 security mechanisms like IPsec that authenticate and optionally 801 encrypt VXLAN traffic. This will, of course, need to be coupled with 802 an authentication infrastructure for authorized endpoints to obtain 803 and distribute credentials. 805 VXLAN overlay networks are designated and operated over the existing 806 LAN infrastructure. To ensure that VXLAN end points and their VTEPs 807 are authorized on the LAN, it is recommended that a VLAN be 808 designated for VXLAN traffic and the servers/VTEPs send VXLAN 809 traffic over this VLAN to provide a measure of security. 811 In addition, VXLAN requires proper mapping of VNIs and VM membership 812 in these overlay networks. It is expected that this mapping be done 813 and communicated to the management entity on the VTEP and the 814 gateways using existing secure methods. 816 8. IANA Considerations 818 A well-known UDP port (4789) has been assigned by the IANA Service 819 Name and Transport Protocol Port Number Registry for VXLAN. See 820 Section 5 for discussion of the port number. 822 9. References 824 9.1. Normative References 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, March 1997. 829 9.2. Informative References 831 [802.1D] "Standard for Local and Metropolitan Area Networks/ 832 Media Access Control (MAC) Bridges, IEEE P802.1D-2004". 834 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I., 835 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 836 Specification", RFC 4601, August 2006. 838 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and Vicisano, L., 839 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 840 5015, October 2007. 842 [RFC4541] Christensen, M., Kimball, K., and Solensky, F., 843 "Considerations for Internet Group Management Protocol (IGMP) 844 and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, 845 May 2006. 847 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 848 Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 849 2011. 851 [802.1aq] "Standard for Local and Metropolitan Area Networks / 852 Virtual Bridged Local Area Networks / Amendment20: Shortest 853 Path Bridging, IEEE P802.1aq-2012". 855 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC1191, 856 November 1990. 858 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 859 for IP version 6", RFC 1981, August 1996. 861 [RFC6335] Cotton, M, Eggert, L., Touch, J., Westerlund, M., and 862 Cheshire, S., "Internet Assigned Numbers Authority (IANA) Procedures 863 for the Management of the Service Name and Transport Protocol Port 864 Number Registry", RFC 6335, August 2011. 866 10. Acknowledgments 868 The authors wish to thank Ajit Sanzgiri for contributions to the 869 Security Considerations section and editorial inputs, Joseph Cheng, 870 Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva 871 Kollipara for their editorial reviews, inputs and comments. 873 Authors' Addresses 875 Mallik Mahalingam 876 Storvisor 877 333 W.El Camino Real 878 Sunnyvale, CA 94087 880 Email: mallik_mahalingam@yahoo.com 882 Dinesh G. Dutt 883 Cumulus Networks 884 140C S.Whisman Road 885 Mountain View, CA 94041 887 Email: ddutt.ietf@hobbesdutt.com 889 Kenneth Duda 890 Arista Networks 891 5470 Great America Parkway 892 Santa Clara, CA 95054 894 Email: kduda@aristanetworks.com 896 Puneet Agarwal 897 Broadcom Corporation 898 3151 Zanker Road 899 San Jose, CA 95134 901 Email: pagarwal@broadcom.com 903 Lawrence Kreeger 904 Cisco Systems, Inc. 905 170 W. Tasman Avenue 906 San Jose, CA 95134 908 Email: kreeger@cisco.com 910 T. Sridhar 911 VMware Inc. 912 3401 Hillview 913 Palo Alto, CA 94304 915 Email: tsridhar@vmware.com 917 Mike Bursell 918 Citrix Systems Research & Development Ltd. 919 Building 101 920 Cambridge Science Park 921 Milton Road 922 Cambridge CB4 0FY 923 United Kingdom 925 Email: mike.bursell@citrix.com 927 Chris Wright 928 Red Hat Inc. 929 1801 Varsity Drive 930 Raleigh, NC 27606 932 Email: chrisw@redhat.com