idnits 2.17.1 draft-mahalingam-dutt-dcops-vxlan-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 14) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 339 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 26 has weird spacing: '...t-Draft is s...' == Line 36 has weird spacing: '... at any ...' == Line 39 has weird spacing: '... The list ...' == Line 112 has weird spacing: '.... This is n...' == Line 125 has weird spacing: '... the indiv...' == (35 more instances...) -- The document date (August 26, 2011) is 4620 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ECMP' is mentioned on line 120, but not defined == Unused Reference: 'RFC4601' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC5015' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'RFC4541' is defined on line 729, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M.Mahalingam 3 Internet Draft VMware 4 Intended Status: Experimental D.Dutt 5 Expires: February 2012 Cisco 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 August 26, 2011 20 VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over 21 Layer 3 Networks 22 draft-mahalingam-dutt-dcops-vxlan-00.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 February 26, 2012. 47 Copyright Notice 49 Copyright (c) 2011 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. 67 Table of Contents 69 1. Introduction...................................................3 70 1.1. Acronyms & Definitions....................................3 71 2. Conventions used in this document..............................4 72 3. VXLAN Problem Statement........................................5 73 3.1. Limitations imposed by Spanning Tree & VLAN Spaces........5 74 3.2. Multitenant Environments..................................5 75 3.3. Inadequate Table Sizes at ToR Switch......................6 76 4. Virtual eXtensible Local Area Network (VXLAN)..................6 77 4.1. Unicast VM to VM communication............................7 78 4.2. Broadcast Communication and Mapping to Multicast..........8 79 4.3. Physical Infrastructure Requirements......................9 80 5. VXLAN Frame Format.............................................9 81 6. VXLAN Deployment Scenarios....................................12 82 6.1. Inner VLAN Tag Handling..................................16 83 7. Security Considerations.......................................16 84 8. IANA Considerations...........................................17 85 9. Conclusions...................................................18 86 10. References...................................................18 87 10.1. Normative References....................................18 88 10.2. Informative References..................................18 89 11. Acknowledgments..............................................18 91 1. Introduction 93 Server virtualization has placed increased demands on the physical 94 network infrastructure. At a minimum, there is a need for more MAC 95 address table entries throughout the switched Ethernet network due 96 to potential attachment of hundreds of thousands of Virtual Machines 97 (VMs), each with its own MAC address. 99 Second, the VMs may be grouped according to their Virtual LAN 100 (VLAN). In a data center 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. A related requirement for virtualized environments is 104 having the Layer 2 network scale across the entire data center or 105 even between data centers for efficient allocation of compute, 106 network and storage resources. Using traditional approaches like 107 Spanning Tree Protocol (STP) for a loop free topology can result in 108 a large number of disabled links in such environments. 110 Another type of demand that is being placed on data centers is the 111 need to host multiple tenants, each with their own isolated network 112 domain. This is not economical to realize with dedicated 113 infrastructure, so network administrators opt to implement this over 114 a shared network. A concomitant problem is that each tenant may 115 independently assign MAC addresses and VLAN IDs leading to potential 116 duplication of these on the physical network. 118 The last scenario is the case where the network operator prefers to 119 use IP for interconnection of the physical infrastructure (e.g. to 120 achieve multipath scalability through Equal Cost Multipath [ECMP]) 121 while still preserving the Layer 2 model for inter-VM communication. 123 The scenarios described above lead to a requirement for an overlay 124 network. This overlay would be used to carry the MAC traffic from 125 the individual VMs in an encapsulated format over a logical 126 "tunnel". 128 This document details a framework termed Virtual eXtensible Local 129 Area Network (VXLAN) which provides such an encapsulation scheme to 130 address the various requirements specified above. 132 1.1. Acronyms & Definitions 134 ACL - Access Control List 136 ECMP - Equal Cost Multipath 137 IGMP - Internet Group Management Protocol 139 PIM - Protocol Independent Multicast 141 STP - Spanning Tree Protocol 143 ToR - Top of Rack 145 TRILL - Transparent Interconnection of Lots of Links 147 VXLAN - Virtual eXtensible Local Area Network 149 VXLAN Segment - VXLAN Layer 2 overlay network over which VMs 151 communicate 153 VXLAN Overlay Network - another term for VXLAN Segment 155 VXLAN Gateway - an entity which forwards traffic between VXLAN 157 and non-VXLAN environments 159 VTEP - VXLAN Tunnel End Point - an entity which originates or 161 terminates VXLAN tunnels 163 VLAN - Virtual Local Area Network 165 VM - Virtual Machine 167 VNI - VXLAN Network Identifier (or VXLAN Segment ID) 169 2. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC-2119 [RFC2119]. 175 In this document, these words will appear with that interpretation 176 only when in ALL CAPS. Lower case uses of these words are not to be 177 interpreted as carrying RFC-2119 significance. 179 3. VXLAN Problem Statement 181 This section details the problems that VXLAN is intended to address. 182 The focus is on the networking infrastructure within the data center 183 and the issues related to them. 185 3.1. Limitations imposed by Spanning Tree & VLAN Spaces 187 Current Layer 2 networks use the Spanning Tree Protocol (STP) to 188 avoid loops in the network due to duplicate paths. STP will turn off 189 links to avoid the replication and looping of frames. Some data 190 center operators see this as a problem with Layer 2 networks in 191 general since with STP they are effectively paying for more ports 192 and links than they can use. In addition, resiliency due to 193 multipathing is not available with the STP model. Newer initiatives 194 like TRILL are being proposed to help with multipathing and thus 195 surmount some of the problems with STP. STP limitations may be 196 avoided by configuring servers within a rack to be on the same Layer 197 3 network with switching happening at Layer 3 both within the rack 198 and between racks. However, this is incompatible with a Layer 2 199 model for inter-VM communication. 201 Another characteristic of Layer 2 data center networks is their use 202 of Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit 203 VLAN ID is used in the Ethernet data frames to divide the larger 204 Layer 2 network into multiple broadcast domains. This has served 205 well for several data centers which are limited to less than 4094 206 VLANs. With the growing adoption of virtualization, this upper limit 207 is seeing pressure. Moreover, due to STP, several data centers limit 208 the number of VLANs that could be used. In addition, requirements 209 for multitenant environments accelerate the need for larger VLAN 210 limits, as discussed in Section 3.3. 212 3.2. Multitenant Environments 214 Cloud computing involves on demand elastic provisioning of resources 215 for multitenant environments. The most common example of cloud 216 computing is the public cloud, where a cloud service provider offers 217 these elastic services to multiple customers over the same 218 infrastructure. 220 Isolation of network traffic by tenant could be done via Layer 2 or 221 Layer 3 networks. For Layer 2 networks, VLANs are often used to 222 segregate traffic - so a tenant could be identified by its own VLAN, 223 for example. Due to the large number of tenants that a cloud 224 provider might service, the 4094 VLAN limit is often inadequate. In 225 addition, there is often a need for multiple VLANs per tenant, which 226 exacerbates the issue. 228 Another use case is cross pod expansion. A pod typically consists of 229 one or more racks of servers with its associated network and storage 230 connectivity. Tenants may start off on a pod and, due to expansion, 231 require servers/VMs on other pods, especially the case when tenants 232 on the other pods are not fully utilizing all their resources. This 233 use case requires a "stretched" Layer 2 environment connecting the 234 individual servers/VMs. 236 Layer 3 networks are not a complete solution for multi tenancy 237 either. Two tenants might use the same set of Layer 3 addresses 238 within their networks which requires the cloud provider to provide 239 isolation in some other form. Further, requiring all tenants to use 240 IP excludes customers relying on direct Layer 2 or non-IP Layer 3 241 protocols for inter VM communication. 243 3.3. Inadequate Table Sizes at ToR Switch 245 Today's virtualized environments place additional demands on the MAC 246 address tables of Top of Rack (ToR) switches which connect to the 247 servers. Instead of just one MAC address per server link, the ToR 248 now has to learn the MAC addresses of the individual VMs (which 249 could range in the 100s per server). This is a requirement since 250 traffic from/to the VMs to the rest of the physical network will 251 traverse the link to the switch. A typical ToR switch could connect 252 to 24 or 48 servers depending upon the number of its server facing 253 ports. A data center might consist of several racks, so each ToR 254 switch would need to maintain an address table for the communicating 255 VMs across the various physical servers. This places a much larger 256 demand on the table capacity compared to non-virtualized 257 environments. 259 If the table overflows, the switch may stop learning new addresses 260 until idle entries age out, leading to significant flooding of 261 unknown destination frames. 263 4. Virtual eXtensible Local Area Network (VXLAN) 265 VXLAN (Virtual eXtensible Local Area Network) addresses the 266 requirements of Layer 2 and Layer 3 data center network 267 infrastructure in the presence of VMs in a multitenant environment. 268 It runs over the existing networking infrastructure and provides a 269 means to "stretch" a Layer 2 network. In short, VXLAN is a Layer 2 270 overlay scheme over a Layer 3 network. Each overlay is termed a 271 VXLAN segment. Only VMs within the same VXLAN segment can 272 communicate with each other. Each VXLAN segment is scoped through a 273 24 bit segment ID, hereafter termed the VXLAN Network Identifier 274 (VNI). This allows up to 16M VXLAN segments to coexist within the 275 same administrative domain. 277 The VNI scopes the inner MAC frame originated by the individual VM. 278 Thus, you could have overlapping MAC addresses across segments but 279 never have traffic "cross over" since the traffic is isolated using 280 the VNI qualifier. This qualifier is in an outer header envelope 281 over the inner MAC frame originated by the VM. In the following 282 sections, the term "VXLAN segment" is used interchangeably with the 283 term "VXLAN overlay network". 285 Due to this encapsulation, VXLAN could also be termed a tunneling 286 scheme to overlay Layer 2 networks on top of Layer 3 networks. The 287 tunnels are stateless, so each frame is encapsulated according to a 288 set of rules. The end point of the tunnel (VTEP) discussed in the 289 following sections is located within the hypervisor on the server 290 which houses the VM. Thus, the VNI and VXLAN related tunnel/outer 291 header encapsulation are known only to the VTEP - the VM never sees 292 it (see Figure 1). Note that it is possible that VTEPs could also be 293 on a physical switch or physical server and could be implemented in 294 software or hardware. One use case where the VTEP is a physical 295 switch is discussed in Section 6 VXLAN on VXLAN deployment 296 scenarios. 298 The following sections discuss typical traffic flow scenarios in a 299 VXLAN environment using one type of control scheme - data plane 300 learning. Here, the association of VM's MAC to VTEP's IP is 301 discovered via source learning. Multicast is used for carrying 302 unknown destination, broadcast and multicast frames. VXLAN 304 4.1. Unicast VM to VM communication 306 Consider a VM within a VXLAN overlay network. This VM is unaware of 307 VXLAN. To communicate with a VM on a different host, it sends a MAC 308 frame destined to the target as before. The VTEP on the physical 309 host looks up the VNI to which this VM is associated. It then 310 determines if the destination MAC is on the same segment. If so, an 311 outer header comprising an outer MAC, outer IP address and VXLAN 312 header (see Figure 1 in Section 5 for frame format) are inserted in 313 front of the original MAC frame. The final packet is transmitted out 314 to the destination, which is the IP address of the remote VTEP 315 connecting the destination VM addressed by the inner MAC destination 316 address. 318 Upon reception, the remote VTEP verifies that the VNI is a valid one 319 and is used by the destination VM. If so, the packet is stripped of 320 its outer header and passed on to the destination VM. The 321 destination VM never knows about the VNI or that the frame was 322 transported with a VXLAN encapsulation. 324 In addition to forwarding the packet to the destination VM, the 325 remote VTEP learns the Inner Source MAC to outer Source IP address 326 mapping. It stores this mapping in a table so that when the 327 destination VM sends a response packet, there is no need for an 328 "unknown destination" flooding of the response packet. 330 Determining the MAC address of the destination VM prior to the 331 transmission by the VM is performed as with non-VXLAN environments 332 except as described below. Broadcast frames are used but are 333 encapsulated within a multicast packet, as detailed in the next 334 section. 336 4.2. Broadcast Communication and Mapping to Multicast 338 Consider the VM on the source host attempting to communicate with 339 the destination VM using IP. Assuming that they are both on the 340 same subnet, the VM sends out an ARP broadcast frame. In the non- 341 VXLAN environment, this frame would be sent out using MAC broadcast 342 which all switches carrying that VLAN. 344 With VXLAN, a header including the VXLAN VNI is inserted at the 345 beginning of the packet along with the IP header and UDP header. 346 However, this broadcast packet is sent out to the IP multicast group 347 on which that VXLAN overlay network is realized. VXLAN 349 To realize this, we need to have a mapping between the VXLAN VNI and 350 the IP multicast group that it will use. This mapping is done at the 351 management layer and provided to the individual VTEPs through a 352 management channel. Using this mapping, the VTEP can provide IGMP 353 membership reports to the upstream switch/router to join/leave the 354 VXLAN related IP multicast groups as needed. This will enable 355 pruning of the leaf nodes for specific multicast traffic addresses 356 based on whether a member is available on this host using that 357 specific multicast address. In addition, use of multicast routing 358 protocols like PIM will provide efficient multicast trees within the 359 Layer 3 network. 361 The VTEP will use (*,G) joins. This is needed as the set of VXLAN 362 tunnel sources is unknown and may change often, as the VMs come 363 up/go down across different hosts. A side note here is that since 364 each VTEP can act as both the source and destination for multicast 365 packets, a protocol like PIM-bidir would be more efficient. 367 The destination VM sends a standard ARP response using IP unicast. 368 This frame will be encapsulated back to the VTEP connecting the 369 originating VM using IP unicast VXLAN encapsulation. This is 370 possible since the mapping of the ARP response's destination MAC to 371 the VXLAN tunnel end point IP was learned earlier through the ARP 372 request. 374 Another point to note is that multicast frames and "unknown MAC 375 destination" frames are also sent using the multicast tree, similar 376 to the broadcast frames. 378 4.3. Physical Infrastructure Requirements 380 When IP multicast is used within the network infrastructure, a 381 multicast routing protocol like Protocol Independent Multicast 382 Sparse Mode (PIM-SM) is used by the individual Layer 3 IP 383 routers/switches within the network. This is used to build efficient 384 multicast forwarding trees so that multicast trees are only sent to 385 those hosts which have requested to receive them. 387 Similarly, there is no requirement that the actual network 388 connecting the source VM and destination VM should be a Layer 3 389 network - VXLAN can also work over Layer 2 networks. In either case, 390 efficient multicast replication within the Layer 2 network can be 391 achieved using IGMP snooping. 393 5. VXLAN Frame Format 395 The VXLAN frame format is shown below. Parsing this from the bottom, 396 there is an inner MAC frame with its own Ethernet header with 397 source, destination MAC addresses along with the Ethernet type plus 398 an optional VLAN tag (see Section 6 for further details of inner 399 VLAN tag handling). 401 The inner MAC frame is encapsulated with the following three headers 402 starting from the innermost header. 404 O VXLAN Header: This is an 8 byte field which has: 406 o Flags (8 bits) where the I flag MUST be set to 1 for a valid 407 VXLAN Network ID (VNI). The remaining 7 bits (designated "R") are 408 reserved fields and MUST be set to zero. 410 o VXLAN Segment ID/VXLAN Network Identifier (VNI) - this is a 24 411 bit value used to designate the individual VXLAN overlay network 412 on which the communicating VMs are situated. VMs in different 413 VXLAN overlay networks cannot communicate. 415 o Reserved fields (24 bits and 8 bits) - MUST be set to zero. 417 O Outer UDP Header: This is the outer UDP header with a source 418 port provided by the VTEP and the destination port being a well 419 known UDP port to be obtained by IANA assignment. It is recommended 420 that the source port be a hash of the inner Ethernet frame's headers 421 to obtain a level of entropy for ECMP/load balancing of the VM to VM 422 traffic across the VXLAN overlay. 424 The UDP checksum field SHOULD be transmitted as zero. When a packet 425 is received with a UDP checksum of zero, it MUST be accepted for 426 decapsulation. Optionally, if the encapsulating endpoint includes 427 a non-zero UDP checksum, it MUST be correctly calculated across the 428 entire packet including the IP header, UDP header, VXLAN header and 429 encapsulated MAC frame. When a decapsulating endpoint receives a 430 packet with a non-zero checksum it MAY choose to verify the 431 checksum value. If it chooses to perform such verification, and the 432 verification fails, the packet MUST be dropped. If the 433 decapsulating destination chooses not to perform the verification, 434 or performs it successfully, the packet MUST be accepted for 435 decapsulation. 437 O Outer IP Header: This is the outer IP header with the source IP 438 address indicating the IP address of the VTEP over which the 439 communicating VM (as depicted by the inner source MAC address) is 440 running. The destination IP address is the IP address of the VTEP 441 connecting the communicating VM as depicted by the inner destination 442 MAC address. 444 O Outer Ethernet Header (example): Figure 1 shows an example of a 445 common encapsulation of the entire IP packet with the VXLAN 446 encapsulation inside an outer Ethernet header. The destination MAC 447 address in this frame may be the address of the target VTEP or an 448 intermediate Layer 3 router. The outer VLAN tag is optional. If 449 present, it may be used for delineating VXLAN traffic on the LAN. 451 0 1 2 3 452 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 454 Outer Ethernet Header: | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Outer Destination MAC Address | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Outer Destination MAC Address | Outer Source MAC Address | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Outer Source MAC Address | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Optional Ethertype = C-Tag 802.1Q | Outer.VLAN Tag Information | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Ethertype 0x0800 | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Outer IP Header: 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |Version| IHL |Type of Service| Total Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Identification |Flags| Fragment Offset | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Time to Live | Protocol | Header Checksum | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Outer Source Address | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Outer Destination Address | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Outer UDP Header: 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Source Port = xxxx | Dest Port = VXLAN Port | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | UDP Length | UDP Checksum | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 VXLAN Header: 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 |R|R|R|R|I|R|R|R| Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | VXLAN Network Identifier (VNI) | Reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 0 1 2 3 491 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 493 Inner Ethernet Header: | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Inner Destination MAC Address | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Inner Destination MAC Address | Inner Source MAC Address | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Inner Source MAC Address | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Optional Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Payload: 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Ethertype of Original Payload | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 507 | Original Ethernet Payload | 508 | | 509 | (Note that the original Ethernet Frame's FCS is not included) | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Frame Check Sequence: 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 1 VXLAN Frame Format 518 The frame format above shows tunneling of Ethernet frames using IPv4 519 for transport. Use of VXLAN with IPv6 transport will be addressed 520 in a future version of this draft. 522 6. VXLAN Deployment Scenarios 524 VXLAN is typically deployed in data centers on virtualized hosts, 525 which may be spread across multiple racks. The individual racks may 526 be parts of a different Layer 3 network or they could be in one 527 Layer 2 network. The VXLAN segments/overlay networks are overlaid on 528 top of these Layer 2 or Layer 3 networks. 530 Consider Figure 2 below depicting two virtualized servers attached 531 to a Layer 3 infrastructure. The servers could be on the same rack, 532 or on different racks or potentially across data centers within the 533 same administrative domain. There are 4 VXLAN overlay networks 534 identified by the VNIs 22, 34, 74 and 98. Consider the case of VM1-1 535 in Server 1 and VM2-4 on Server 2 which are on the same VXLAN 536 overlay network identified by VNI 22. The VMs do not know about the 537 overlay networks and transport method since the encapsulation and 538 decapsulation happen transparently at the VTEPs on Servers 1 and 2. 539 The other overlay networks and the corresponding VMs are: VM1-2 on 540 Server 1 and VM2-1 on Server 2 both on VNI 34, VM1-3 on Server 1 and 541 VM2-2 on Server 2 on VNI 74, and finally VM1-4 on Server 1 and VM2-3 542 on Server 2 on VNI 98. 544 +------------+-------------+ 545 | Server 1 | 546 | +----+----+ +----+----+ | 547 | |VM1-1 | |VM1-2 | | 548 | |VNI 22 | |VNI 34 | | 549 | | | | | | 550 | +---------+ +---------+ | 551 | | 552 | +----+----+ +----+----+ | 553 | |VM1-3 | |VM1-4 | | 554 | |VNI 74 | |VNI 98 | | 555 | | | | | | 556 | +---------+ +---------+ | 557 | Hypervisor VTEP (IP1) | 558 +--------------------------+ 559 | 560 | 561 | 562 | 563 | 564 | 565 | +-------------+ 566 | | Layer 3 | 567 |---| Network | 568 | | 569 +-------------+ 570 | 571 | 572 +---------+ 573 | 574 +------------+-------------+ 575 | Server 2 | 576 | +----+----+ +----+----+ | 577 | |VM2-1 | |VM2-2 | | 578 | |VNI 34 | |VNI 74 | | 579 | | | | | | 580 | +---------+ +---------+ | 581 | | 582 | +----+----+ +----+----+ | 583 | |VM2-3 | |VM2-4 | | 584 | |VNI 98 | |VNI 22 | | 585 | | | | | | 586 | +---------+ +---------+ | 587 | Hypervisor VTEP (IP2) | 588 +--------------------------+ 590 Figure 2 VXLAN Deployment - VTEPs across a Layer 3 Network 592 One deployment scenario is where the tunnel termination point is a 593 physical server which understands VXLAN. Another scenario is where 594 nodes on a VXLAN overlay network need to communicate with nodes on 595 legacy networks which could be VLAN based. These nodes may be 596 physical nodes or virtual machines. To enable this communication, a 597 network can include VXLAN gateways (see Figure 3 below with a switch 598 acting as a VXLAN gateway) which forward traffic between VXLAN and 599 non-VXLAN environments. 601 Consider Figure 3 for the following discussion. For incoming frames 602 on the VXLAN connected interface, the gateway strips out the VXLAN 603 header and forwards to a physical port based on the destination MAC 604 address of the inner Ethernet frame. Decapsulated frames with the 605 inner VLAN ID SHOULD be discarded unless configured explicitly to be 606 passed on to the non-VXLAN interface. In the reverse direction, 607 incoming frames for the non-VXLAN interfaces are mapped to a 608 specific VXLAN overlay network based on the VLAN ID in the frame. 609 Unless configured explicitly to be passed on in the encapsulated 610 VXLAN frame, this VLAN ID is removed before the frame is 611 encapsulated for VXLAN. 613 These gateways which provide VXLAN tunnel termination functions 614 could be ToR/access switches or switches higher up in the data 615 center network topology - e.g. core or even WAN edge devices. The 616 last case (WAN edge) could involve a Provider Edge (PE) router which 617 terminates VXLAN tunnels in a hybrid cloud environment. Note that in 618 all these instances, the gateway functionality could be implemented 619 in software or hardware. 621 +---+-----+---+ +---+-----+---+ 622 | Server 1 | | Non VXLAN | 623 (VXLAN enabled)<-----+ +---->| server | 624 +-------------+ | | +-------------+ 625 | | 626 +---+-----+---+ | | +---+-----+---+ 627 |Server 2 | | | | Non VXLAN | 628 (VXLAN enabled)<-----+ +---+-----+---+ +---->| server | 629 +-------------+ | |Switch acting| | +-------------+ 630 |---| as VXLAN |-----| 631 +---+-----+---+ | | Gateway | 632 | Server 3 | | +-------------+ 633 (VXLAN enabled)<-----+ 634 +-------------+ | 635 | 636 +---+-----+---+ | 637 | Server 4 | | 638 (VXLAN enabled)<-----+ 639 +-------------+ 640 Figure 3 VXLAN Deployment - VXLAN Gateway 642 6.1. Inner VLAN Tag Handling 644 Inner VLAN Tag Handling in VTEP and VXLAN Gateway should conform to 645 the following: 647 Decapsulated VXLAN frames with the inner VLAN tag SHOULD be 648 discarded unless configured otherwise. On the encapsulation side, a 649 VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless 650 configured otherwise. When a VLAN-tagged packet is a candidate for 651 VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag 652 unless configured otherwise. 654 7. Security Considerations 656 Traditionally, layer 2 networks can only be attacked from 'within' 657 by rogue endpoints - either by having inappropriate access to a LAN 658 and snooping on traffic or by injecting spoofed packets to 'take 659 over' another MAC address or by flooding and causing denial of 660 service. A MAC-over-IP mechanism for delivering Layer 2 traffic 661 significantly extends this attack surface. This can happen by rogues 662 injecting themselves into the network by subscribing to one or 663 more multicast groups that carry broadcast traffic for VXLAN 664 segments and also by sourcing MAC-over-UDP frames into the transport 665 network to inject spurious traffic, possibly to hijack MAC 666 addresses. 668 This proposal does not, at this time, incorporate specific measures 669 against such attacks, relying instead on other traditional 670 mechanisms layered on top of IP. This section, instead, sketches 671 out some possible approaches to security in the VXLAN environment. 673 Traditional Layer 2 attacks by rogue end points can be mitigated by 674 limiting the management and administrative scope of who deploys and 675 manages VMs/gateways in a VXLAN environment. In addition, such 676 administrative measures may be augmented by schemes like 802.1X for 677 admission control of individual end points. Also, the use of the 678 UDP based encapsulation of VXLAN enables exploiting the 5 tuple 679 based ACLs (Access Control Lists) functionality in physical 680 switches. 682 Tunneled traffic over the IP network can be secured with traditional 683 IPSEC mechanisms that authenticate and optionally encrypt VXLAN 684 traffic. This will, of course, need to be coupled with an 685 authentication infrastructure for authorized endpoints to obtain and 686 distribute credentials. 688 VXLAN overlay networks are designated and operated over the existing 689 LAN infrastructure. To ensure that VXLAN end points and their VTEPs 690 are authorized on the LAN, it is recommended that a VLAN be 691 designated for VXLAN traffic and the servers/VTEPs send VXLAN 692 traffic over this VLAN to provide a measure of security. 694 In addition, VXLAN requires proper mapping of VNIs and VM membership 695 in these overlay networks. It is expected that this mapping be done 696 and communicated to the management entity on the VTEP and the 697 gateways using existing secure methods. 699 8. IANA Considerations 701 An IANA port will be requested for the VXLAN destination UDP port. 703 9. Conclusions 705 This document has introduced VXLAN, an overlay framework for 706 transporting MAC frames generated by VMs in isolated Layer 2 707 networks over an IP network. Through this scheme, it is possible to 708 stretch Layer 2 networks across Layer 3 networks. This finds use in 709 virtualized data center environments where Layer 2 networks may need 710 to span across the entire data center, or even between data centers. 712 10. References 714 10.1. Normative References 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 10.2. Informative References 721 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I., 722 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 723 Specification", RFC 4601, August 2006. 725 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and Vicisano, L., 726 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 727 5015, October 2007. 729 [RFC4541] Christensen, M., Kimball, K., and Solensky, F., 730 "Considerations for Internet Group Management Protocol (IGMP) 731 and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, 732 May 2006. 734 11. Acknowledgments 736 The authors wish to thank Ajit Sanzgiri for contributions to the 737 Security Considerations section and editorial inputs, Joseph Cheng, 738 Margaret Petrus and Milin Desai for their editorial reviews, inputs 739 and comments. 741 Authors' Addresses 743 Mallik Mahalingam 744 VMware Inc. 745 3401 Hillview 746 Palo Alto, CA 94304 748 Email: mallik@vmware.com 750 Dinesh G. Dutt 751 Cisco Systems, Inc. 752 170 W. Tasman Avenue 753 Palo Alto, CA 94304 755 Email: ddutt@cisco.com 757 Kenneth Duda 758 Arista Networks 759 5470 Great America Parkway 760 Santa Clara, CA 95054 762 Email: kduda@aristanetworks.com 764 Puneet Agarwal 765 Broadcom Corporation 766 3151 Zanker Road 767 San Jose, CA 95134 769 Email: pagarwal@broadcom.com 771 Lawrence Kreeger 772 Cisco Systems, Inc. 773 170 W. Tasman Avenue 774 Palo Alto, CA 94304 776 Email: kreeger@cisco.com 778 T. Sridhar 779 VMware Inc. 780 3401 Hillview 781 Palo Alto, CA 94304 783 Email: tsridhar@vmware.com 784 Mike Bursell 785 Citrix Systems Research & Development Ltd. 786 Building 101 787 Cambridge Science Park 788 Milton Road 789 Cambridge CB4 0FY 790 United Kingdom 792 Email: mike.bursell@citrix.com 794 Chris Wright 795 Red Hat Inc. 796 1801 Varsity Drive 797 Raleigh, NC 27606 799 Email: chrisw@redhat.com