idnits 2.17.1 draft-mahalingam-dutt-dcops-vxlan-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 422 instances of too long lines in the document, the longest one being 11 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 25 has weird spacing: '...t-Draft is s...' == Line 35 has weird spacing: '... at any ...' == Line 38 has weird spacing: '... The list ...' == Line 112 has weird spacing: '.... This is n...' == Line 125 has weird spacing: '... the indiv...' == (36 more instances...) -- The document date (May 8, 2013) is 4006 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 835, but no explicit reference was found in the text == Unused Reference: 'RFC5015' is defined on line 839, but no explicit reference was found in the text == Unused Reference: 'RFC4541' is defined on line 843, 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 (~~), 12 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 D. Dutt 4 Intended Status: Experimental Cumulus Networks 5 Expires: November 2013 K. Duda 6 Arista 7 P. Agarwal 8 Broadcom 9 L. Kreeger 10 Cisco 11 T. Sridhar 12 VMware 13 M. Bursell 14 Citrix 15 C. Wright 16 Red Hat 17 May 8, 2013 19 VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over 20 Layer 3 Networks 21 draft-mahalingam-dutt-dcops-vxlan-04.txt 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on November 8, 2013. 46 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. 58 Abstract 60 This document describes Virtual eXtensible Local Area Network 61 (VXLAN), which is used to address the need for overlay networks 62 within virtualized data centers accommodating multiple tenants. The 63 scheme and the related protocols can be used in cloud service 64 provider and enterprise data center networks. 66 Table of Contents 68 1. Introduction...................................................3 69 1.1. Acronyms & Definitions....................................3 70 2. Conventions used in this document..............................4 71 3. VXLAN Problem Statement........................................5 72 3.1. Limitations imposed by Spanning Tree & VLAN Ranges........5 73 3.2. Multitenant Environments..................................5 74 3.3. Inadequate Table Sizes at ToR Switch......................6 75 4. Virtual eXtensible Local Area Network (VXLAN)..................6 76 4.1. Unicast VM to VM communication............................7 77 4.2. Broadcast Communication and Mapping to Multicast..........8 78 4.3. Physical Infrastructure Requirements......................9 79 5. VXLAN Frame Format.............................................9 80 6. VXLAN Deployment Scenarios....................................14 81 6.1. Inner VLAN Tag Handling..................................18 82 7. IETF Network Virtualization Overlays (nvo3) Working Group.....18 83 8. Security Considerations.......................................19 84 9. IANA Considerations...........................................20 85 10. Conclusion...................................................20 86 11. References...................................................20 87 11.1. Normative References....................................20 88 11.2. Informative References..................................20 89 12. Acknowledgments..............................................21 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 138 IGMP - Internet Group Management Protocol 140 PIM - Protocol Independent Multicast 142 SPB - Shortest Path Bridging 144 STP - Spanning Tree Protocol 146 ToR - Top of Rack 148 TRILL - Transparent Interconnection of Lots of Links 150 VXLAN - Virtual eXtensible Local Area Network 152 VXLAN Segment - VXLAN Layer 2 overlay network over which VMs 154 communicate 156 VXLAN Overlay Network - another term for VXLAN Segment 158 VXLAN Gateway - an entity which forwards traffic between VXLAN 160 and non-VXLAN environments 162 VTEP - VXLAN Tunnel End Point - an entity which originates 163 and/or terminates VXLAN tunnels 165 VLAN - Virtual Local Area Network 167 VM - Virtual Machine 169 VNI - VXLAN Network Identifier (or VXLAN Segment ID) 171 2. Conventions used in this document 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC-2119 [RFC2119]. 177 In this document, these words will appear with that interpretation 178 only when in ALL CAPS. Lower case uses of these words are not to be 179 interpreted as carrying RFC-2119 significance. 181 3. VXLAN Problem Statement 183 This section details the problems that VXLAN is intended to address. 184 The focus is on the networking infrastructure within the data center 185 and the issues related to them. 187 3.1. Limitations imposed by Spanning Tree & VLAN Ranges 189 Current Layer 2 networks use the Spanning Tree Protocol (STP) to 190 avoid loops in the network due to duplicate paths. STP will turn off 191 links to avoid the replication and looping of frames. Some data 192 center operators see this as a problem with Layer 2 networks in 193 general since with STP they are effectively paying for more ports 194 and links than they can really use. In addition, resiliency due to 195 multipathing is not available with the STP model. Newer initiatives 196 like TRILL/Shortest Path Bridging (SPB) have been proposed to help 197 with multipathing and thus surmount some of the problems with STP. 198 STP limitations may also be avoided by configuring servers within a 199 rack to be on the same Layer 3 network with switching happening at 200 Layer 3 both within the rack and between racks. However, this is 201 incompatible with a Layer 2 model for inter-VM communication. 203 Another characteristic of Layer 2 data center networks is their use 204 of Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit 205 VLAN ID is used in the Ethernet data frames to divide the larger 206 Layer 2 network into multiple broadcast domains. This has served 207 well for several data centers which require fewer than 4094 VLANs. 208 With the growing adoption of virtualization, this upper limit is 209 seeing pressure. Moreover, due to STP, several data centers limit 210 the number of VLANs that could be used. In addition, requirements 211 for multitenant environments accelerate the need for larger VLAN 212 limits, as discussed in Section 3.3. 214 3.2. Multitenant Environments 216 Cloud computing involves on demand elastic provisioning of resources 217 for multitenant environments. The most common example of cloud 218 computing is the public cloud, where a cloud service provider offers 219 these elastic services to multiple customers/tenants over the same 220 physical infrastructure. 222 Isolation of network traffic by tenant could be done via Layer 2 or 223 Layer 3 networks. For Layer 2 networks, VLANs are often used to 224 segregate traffic - so a tenant could be identified by its own VLAN, 225 for example. Due to the large number of tenants that a cloud 226 provider might service, the 4094 VLAN limit is often inadequate. In 227 addition, there is often a need for multiple VLANs per tenant, which 228 exacerbates the issue. 230 Another use case is cross pod expansion. A pod typically consists of 231 one or more racks of servers with associated network and storage 232 connectivity. Tenants may start off on a pod and, due to expansion, 233 require servers/VMs on other pods, especially the case when tenants 234 on the other pods are not fully utilizing all their resources. This 235 use case requires a "stretched" Layer 2 environment connecting the 236 individual servers/VMs. 238 Layer 3 networks are not a complete solution for multi tenancy 239 either. Two tenants might use the same set of Layer 3 addresses 240 within their networks which requires the cloud provider to provide 241 isolation in some other form. Further, requiring all tenants to use 242 IP excludes customers relying on direct Layer 2 or non-IP Layer 3 243 protocols for inter VM communication. 245 3.3. Inadequate Table Sizes at ToR Switch 247 Today's virtualized environments place additional demands on the MAC 248 address tables of Top of Rack (ToR) switches which connect to the 249 servers. Instead of just one MAC address per server link, the ToR 250 now has to learn the MAC addresses of the individual VMs (which 251 could range in the 100s per server). This is a requirement since 252 traffic from/to the VMs to the rest of the physical network will 253 traverse the link to the switch. A typical ToR switch could connect 254 to 24 or 48 servers depending upon the number of its server facing 255 ports. A data center might consist of several racks, so each ToR 256 switch would need to maintain an address table for the communicating 257 VMs across the various physical servers. This places a much larger 258 demand on the table capacity compared to non-virtualized 259 environments. 261 If the table overflows, the switch may stop learning new addresses 262 until idle entries age out, leading to significant flooding of 263 subsequent unknown destination frames. 265 4. Virtual eXtensible Local Area Network (VXLAN) 267 VXLAN (Virtual eXtensible Local Area Network) addresses the above 268 requirements of the Layer 2 and Layer 3 data center network 269 infrastructure in the presence of VMs in a multitenant environment. 270 It runs over the existing networking infrastructure and provides a 271 means to "stretch" a Layer 2 network. In short, VXLAN is a Layer 2 272 overlay scheme over a Layer 3 network. Each overlay is termed a 273 VXLAN segment. Only VMs within the same VXLAN segment can 274 communicate with each other. Each VXLAN segment is scoped through a 275 24 bit segment ID, hereafter termed the VXLAN Network Identifier 276 (VNI). This allows up to 16M VXLAN segments to coexist within the 277 same administrative domain. 279 The VNI scopes the inner MAC frame originated by the individual VM. 280 Thus, you could have overlapping MAC addresses across segments but 281 never have traffic "cross over" since the traffic is isolated using 282 the VNI qualifier. This qualifier is in an outer header envelope 283 over the inner MAC frame originated by the VM. In the following 284 sections, the term "VXLAN segment" is used interchangeably with the 285 term "VXLAN overlay network". 287 Due to this encapsulation, VXLAN could also be termed a tunneling 288 scheme to overlay Layer 2 networks on top of Layer 3 networks. The 289 tunnels are stateless, so each frame is encapsulated according to a 290 set of rules. The end point of the tunnel (VTEP) discussed in the 291 following sections is located within the hypervisor on the server 292 which houses the VM. Thus, the VNI and VXLAN related tunnel/outer 293 header encapsulation are known only to the VTEP - the VM never sees 294 it (see Figure 1). Note that it is possible that VTEPs could also be 295 on a physical switch or physical server and could be implemented in 296 software or hardware. One use case where the VTEP is a physical 297 switch is discussed in Section 6 on VXLAN deployment scenarios. 299 The following sections discuss typical traffic flow scenarios in a 300 VXLAN environment using one type of control scheme - data plane 301 learning. Here, the association of VM's MAC to VTEP's IP is 302 discovered via source learning. Multicast is used for carrying 303 unknown destination, broadcast and multicast frames. 305 In addition to a learning based control plane, there are other 306 schemes possible for the distribution of the VTEP IP to VM MAC 307 mapping information. Options could include a central directory based 308 lookup by the individual VTEPs, distribution of this mapping 309 information to the VTEPs by the central directory, and so on. These 310 are sometimes characterized as push and pull models respectively. 311 This draft will focus on the data plane learning scheme as the 312 control plane for VXLAN. 314 4.1. Unicast VM to VM communication 316 Consider a VM within a VXLAN overlay network. This VM is unaware of 317 VXLAN. To communicate with a VM on a different host, it sends a MAC 318 frame destined to the target as before. The VTEP on the physical 319 host looks up the VNI to which this VM is associated. It then 320 determines if the destination MAC is on the same segment and if 321 there is a mapping of the destination MAC address to 322 the remote VTEP. If so, an outer header comprising an outer MAC, 323 outer IP address and VXLAN header (see Figure 1 in Section 5 for 324 frame format) are inserted in front of the original MAC frame. The 325 final packet is transmitted out to the destination. This is the IP 326 address of the remote VTEP connecting the destination VM 327 (represented by the inner MAC destination address). 329 Upon reception, the remote VTEP verifies the validity of the VNI and 330 if there is a VM on that VNI using a MAC address that matches the 331 inner destination MAC address. If so, the packet is stripped of its 332 outer header and passed on to the destination VM. The destination VM 333 never knows about the VNI or that the frame was transported with a 334 VXLAN encapsulation. 336 In addition to forwarding the packet to the destination VM, the 337 remote VTEP learns the Inner Source MAC to outer Source IP address 338 mapping. It stores this mapping in a table so that when the 339 destination VM sends a response packet, there is no need for an 340 "unknown destination" flooding of the response packet. 342 Determining the MAC address of the destination VM prior to the 343 transmission by the source VM is performed as with non-VXLAN 344 environments except as described below. Broadcast frames are used 345 but are encapsulated within a multicast packet, as detailed in the 346 next section. 348 4.2. Broadcast Communication and Mapping to Multicast 350 Consider the VM on the source host attempting to communicate with 351 the destination VM using IP. Assuming that they are both on the 352 same subnet, the VM sends out an ARP broadcast frame. In the non- 353 VXLAN environment, this frame would be sent out using MAC broadcast 354 across all switches carrying that VLAN. 356 With VXLAN, a header including the VXLAN VNI is inserted at the 357 beginning of the packet along with the IP header and UDP header. 358 However, this broadcast packet is sent out to the IP multicast group 359 on which that VXLAN overlay network is realized. 361 To effect this, we need to have a mapping between the VXLAN VNI and 362 the IP multicast group that it will use. This mapping is done at the 363 management layer and provided to the individual VTEPs through a 364 management channel. Using this mapping, the VTEP can provide IGMP 365 membership reports to the upstream switch/router to join/leave the 366 VXLAN related IP multicast groups as needed. This will enable 367 pruning of the leaf nodes for specific multicast traffic addresses 368 based on whether a member is available on this host using the 369 specific multicast address. In addition, use of multicast routing 370 protocols like Protocol Independent Multicast - Sparse Mode (PIM-SM) 371 will provide efficient multicast trees within the Layer 3 network. 373 The VTEP will use (*,G) joins. This is needed as the set of VXLAN 374 tunnel sources is unknown and may change often, as the VMs come 375 up/go down across different hosts. A side note here is that since 376 each VTEP can act as both the source and destination for multicast 377 packets, a protocol like PIM-bidir would be more efficient. 379 The destination VM sends a standard ARP response using IP unicast. 380 This frame will be encapsulated back to the VTEP connecting the 381 originating VM using IP unicast VXLAN encapsulation. This is 382 possible since the mapping of the ARP response's destination MAC to 383 the VXLAN tunnel end point IP was learned earlier through the ARP 384 request. 386 Another point to note is that multicast frames and "unknown MAC 387 destination" frames are also sent using the multicast tree, similar 388 to the broadcast frames. 390 4.3. Physical Infrastructure Requirements 392 When IP multicast is used within the network infrastructure, a 393 multicast routing protocol like PIM-SM can be used by the individual 394 Layer 3 IP routers/switches within the network. This is used to 395 build efficient multicast forwarding trees so that multicast frames 396 are only sent to those hosts which have requested to receive them. 398 Similarly, there is no requirement that the actual network 399 connecting the source VM and destination VM should be a Layer 3 400 network - VXLAN can also work over Layer 2 networks. In either case, 401 efficient multicast replication within the Layer 2 network can be 402 achieved using IGMP snooping. 404 5. VXLAN Frame Format 406 The VXLAN frame format is shown below. Parsing this from the bottom, 407 there is an inner MAC frame with its own Ethernet header with 408 source, destination MAC addresses along with the Ethernet type plus 409 an optional VLAN. One use case of the inner VLAN tag is with VM 410 based VLAN tagging in a virtualized environment. See Section 6 for 411 further details of inner VLAN tag handling. 413 The inner MAC frame is encapsulated with the following four headers 414 (starting from the innermost header): 416 O VXLAN Header: This is an 8 byte field which has: 418 o Flags (8 bits)- where the I flag MUST be set to 1 for a valid 419 VXLAN Network ID (VNI). The other 7 bits (designated "R") are 420 reserved fields and MUST be set to zero. 422 o VXLAN Segment ID/VXLAN Network Identifier (VNI) - this is a 24 423 bit value used to designate the individual VXLAN overlay network 424 on which the communicating VMs are situated. VMs in different 425 VXLAN overlay networks cannot communicate with each other. 427 o Reserved fields (24 bits and 8 bits) - MUST be set to zero. 429 O Outer UDP Header: This is the outer UDP header with a source 430 port provided by the VTEP and the destination port being a well- 431 known UDP port. IANA has assigned the value 4789 for the VXLAN UDP 432 port and this value SHOULD be used by default as the destination UDP 433 port. Some early implementations of VXLAN have used other values 434 for the destination port. To enable interoperability with these 435 implementations, the destination port SHOULD be configurable. It is 436 recommended that the source port number be calculated using a hash 437 of fields from the inner packet - one example being a hash of the 438 inner Ethernet frame`s headers. This is to enable a level of entropy 439 for ECMP/load balancing of the VM to VM traffic across the VXLAN 440 overlay. 442 The UDP checksum field SHOULD be transmitted as zero. When a packet 443 is received with a UDP checksum of zero, it MUST be accepted for 444 decapsulation. Optionally, if the encapsulating endpoint includes a 445 non-zero UDP checksum, it MUST be correctly calculated across the 446 entire packet including the IP header, UDP header, VXLAN header and 447 encapsulated MAC frame. When a decapsulating endpoint receives a 448 packet with a non-zero checksum it MAY choose to verify the 449 checksum value. If it chooses to perform such verification, and the 450 verification fails, the packet MUST be dropped. If the 451 decapsulating destination chooses not to perform the verification, 452 or performs it successfully, the packet MUST be accepted for 453 decapsulation. 455 O Outer IP Header: This is the outer IP header with the source IP 456 address indicating the IP address of the VTEP over which the 457 communicating VM (as represented by the inner source MAC address) is 458 running. The destination IP address can be a unicast or multicast 459 IP address (see Sections 4.1 and 4.2). When it is a unicast IP 460 address, it represents the IP address of the VTEP connecting the 461 communicating VM as represented by the inner destination MAC 462 address. For multicast destination IP addresses, please refer to the 463 scenarios detailed in Section 4.2. 465 O Outer Ethernet Header (example): Figure 1 is an example of an 466 inner Ethernet frame encapsulated within an outer Ethernet + IP + 467 UDP + VXLAN header. The outer destination MAC address in this frame 468 may be the address of the target VTEP or of an intermediate Layer 3 469 router. The outer VLAN tag is optional. If present, it may be used 470 for delineating VXLAN traffic on the LAN. 472 0 1 2 3 473 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 475 Outer Ethernet Header: | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Outer Destination MAC Address | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Outer Destination MAC Address | Outer Source MAC Address | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Outer Source MAC Address | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Optional Ethertype = C-Tag 802.1Q | Outer.VLAN Tag Information | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Ethertype = 0x0800 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Outer IPv4 Header: 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 |Version| IHL |Type of Service| Total Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Identification |Flags| Fragment Offset | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Time to Live |Protocl=17(UDP)| Header Checksum | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Outer Source IPv4 Address | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Outer Destination IPv4 Address | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Outer UDP Header: 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Source Port = xxxx | Dest Port = VXLAN Port | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | UDP Length | UDP Checksum | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 VXLAN Header: 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 |R|R|R|R|I|R|R|R| Reserved | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | VXLAN Network Identifier (VNI) | Reserved | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 514 Inner Ethernet Header: | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Inner Destination MAC Address | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Inner Destination MAC Address | Inner Source MAC Address | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Inner Source MAC Address | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Optional Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Payload: 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Ethertype of Original Payload | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 528 | Original Ethernet Payload | 529 | | 530 | (Note that the original Ethernet Frame's FCS is not included) | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Frame Check Sequence: 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 1 VXLAN Frame Format with IPv4 Outer Header 539 The frame format above shows tunneling of Ethernet frames using IPv4 540 for transport. Use of VXLAN with IPv6 transport is detailed below. 542 0 1 2 3 543 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 545 Outer Ethernet Header: | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Outer Destination MAC Address | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Outer Destination MAC Address | Outer Source MAC Address | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Outer Source MAC Address | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Optional Ethertype = C-Tag 802.1Q| Outer.VLAN Tag Information | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Ethertype = 0x86DD | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Outer IPv6 Header: 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |Version| Traffic Class | Flow Label | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | 564 + + 565 | | 566 + Outer Source IPv6 Address + 567 | | 568 + + 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 + + 573 | | 574 + Outer Destination IPv6 Address + 575 | | 576 + + 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Outer UDP Header: 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Source Port = xxxx | Dest Port = VXLAN Port | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | UDP Length | UDP Checksum | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 VXLAN Header: 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 |R|R|R|R|I|R|R|R| Reserved | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | VXLAN Network Identifier (VNI) | Reserved | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 Inner Ethernet Header: 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Inner Destination MAC Address | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Inner Destination MAC Address | Inner Source MAC Address | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Inner Source MAC Address | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Optional Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Payload: 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Ethertype of Original Payload | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 608 | Original Ethernet Payload | 609 | | 610 | (Note that the original Ethernet Frame's FCS is not included) | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Frame Check Sequence: 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 2 VXLAN Frame Format with IPv6 Outer Header 619 6. VXLAN Deployment Scenarios 621 VXLAN is typically deployed in data centers on virtualized hosts, 622 which may be spread across multiple racks. The individual racks may 623 be parts of a different Layer 3 network or they could be in a single 624 Layer 2 network. The VXLAN segments/overlay networks are overlaid on 625 top of these Layer 2 or Layer 3 networks. 627 Consider Figure 3 below depicting two virtualized servers attached 628 to a Layer 3 infrastructure. The servers could be on the same rack, 629 or on different racks or potentially across data centers within the 630 same administrative domain. There are 4 VXLAN overlay networks 631 identified by the VNIs 22, 34, 74 and 98. Consider the case of VM1-1 632 in Server 1 and VM2-4 on Server 2 which are on the same VXLAN 633 overlay network identified by VNI 22. The VMs do not know about the 634 overlay networks and transport method since the encapsulation and 635 decapsulation happen transparently at the VTEPs on Servers 1 and 2. 636 The other overlay networks and the corresponding VMs are: VM1-2 on 637 Server 1 and VM2-1 on Server 2 both on VNI 34, VM1-3 on Server 1 and 638 VM2-2 on Server 2 on VNI 74, and finally VM1-4 on Server 1 and VM2-3 639 on Server 2 on VNI 98. 641 +------------+-------------+ 642 | Server 1 | 643 | +----+----+ +----+----+ | 644 | |VM1-1 | |VM1-2 | | 645 | |VNI 22 | |VNI 34 | | 646 | | | | | | 647 | +---------+ +---------+ | 648 | | 649 | +----+----+ +----+----+ | 650 | |VM1-3 | |VM1-4 | | 651 | |VNI 74 | |VNI 98 | | 652 | | | | | | 653 | +---------+ +---------+ | 654 | Hypervisor VTEP (IP1) | 655 +--------------------------+ 656 | 657 | 658 | 659 | 660 | 661 | 662 | +-------------+ 663 | | Layer 3 | 664 |---| Network | 665 | | 666 +-------------+ 667 | 668 | 669 +------------+ 670 | 671 +------------+-------------+ 672 | Server 2 | 673 | +----+----+ +----+----+ | 674 | |VM2-1 | |VM2-2 | | 675 | |VNI 34 | |VNI 74 | | 676 | | | | | | 677 | +---------+ +---------+ | 678 | | 679 | +----+----+ +----+----+ | 680 | |VM2-3 | |VM2-4 | | 681 | |VNI 98 | |VNI 22 | | 682 | | | | | | 683 | +---------+ +---------+ | 684 | Hypervisor VTEP (IP2) | 685 +--------------------------+ 687 Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network 689 One deployment scenario is where the tunnel termination point is a 690 physical server which understands VXLAN. Another scenario is where 691 nodes on a VXLAN overlay network need to communicate with nodes on 692 legacy networks which could be VLAN based. These nodes may be 693 physical nodes or virtual machines. To enable this communication, a 694 network can include VXLAN gateways (see Figure 4 below with a switch 695 acting as a VXLAN gateway) which forward traffic between VXLAN and 696 non-VXLAN environments. 698 Consider Figure 4 for the following discussion. For incoming frames 699 on the VXLAN connected interface, the gateway strips out the VXLAN 700 header and forwards to a physical port based on the destination MAC 701 address of the inner Ethernet frame. Decapsulated frames with the 702 inner VLAN ID SHOULD be discarded unless configured explicitly to be 703 passed on to the non-VXLAN interface. In the reverse direction, 704 incoming frames for the non-VXLAN interfaces are mapped to a 705 specific VXLAN overlay network based on the VLAN ID in the frame. 706 Unless configured explicitly to be passed on in the encapsulated 707 VXLAN frame, this VLAN ID is removed before the frame is 708 encapsulated for VXLAN. 710 These gateways which provide VXLAN tunnel termination functions 711 could be ToR/access switches or switches higher up in the data 712 center network topology - e.g. core or even WAN edge devices. The 713 last case (WAN edge) could involve a Provider Edge (PE) router which 714 terminates VXLAN tunnels in a hybrid cloud environment. Note that in 715 all these instances, the gateway functionality could be implemented 716 in software or hardware. 718 +---+-----+---+ +---+-----+---+ 719 | Server 1 | | Non VXLAN | 720 (VXLAN enabled)<-----+ +---->| server | 721 +-------------+ | | +-------------+ 722 | | 723 +---+-----+---+ | | +---+-----+---+ 724 |Server 2 | | | | Non VXLAN | 725 (VXLAN enabled)<-----+ +---+-----+---+ +---->| server | 726 +-------------+ | |Switch acting| | +-------------+ 727 |---| as VXLAN |-----| 728 +---+-----+---+ | | Gateway | 729 | Server 3 | | +-------------+ 730 (VXLAN enabled)<-----+ 731 +-------------+ | 732 | 733 +---+-----+---+ | 734 | Server 4 | | 735 (VXLAN enabled)<-----+ 736 +-------------+ 737 Figure 4 VXLAN Deployment - VXLAN Gateway 739 6.1. Inner VLAN Tag Handling 741 Inner VLAN Tag Handling in VTEP and VXLAN Gateway should conform to 742 the following: 744 Decapsulated VXLAN frames with the inner VLAN tag SHOULD be 745 discarded unless configured otherwise. On the encapsulation side, a 746 VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless 747 configured otherwise. When a VLAN-tagged packet is a candidate for 748 VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag 749 unless configured otherwise. 751 7. IETF Network Virtualization Overlays (nvo3) Working Group 753 The IETF has recently chartered the Network Virtualization Overlays 754 (nvo3) Working Group (WG) under the Routing Area. The charter 755 (http://datatracker.ietf.org/wg/nvo3/charter/) indicates that the WG 756 will consider the multi tenancy approaches residing at the network 757 layer. The WG will provide a problem statement, architectural 758 framework and requirements for the control and data plane for such 759 network virtualization overlay schemes. Operations, Administration 760 and Management (OA&M) requirements for the nvo3 are also within the 761 scope of the WG. The active Internet drafts being considered by the 762 working group are at http://datatracker.ietf.org/wg/nvo3/. This 763 draft on VXLAN addresses the requirements outlined in the nvo3 WG 764 charter. It outlines the data plane requirements as well as the 765 method to establish the forwarding entries in each VTEP. 767 8. Security Considerations 769 Traditionally, layer 2 networks can only be attacked from 'within' 770 by rogue endpoints - either by having inappropriate access to a LAN 771 and snooping on traffic or by injecting spoofed packets to 'take 772 over' another MAC address or by flooding and causing denial of 773 service. A MAC-over-IP mechanism for delivering Layer 2 traffic 774 significantly extends this attack surface. This can happen by rogues 775 injecting themselves into the network by subscribing to one or 776 more multicast groups that carry broadcast traffic for VXLAN 777 segments and also by sourcing MAC-over-UDP frames into the transport 778 network to inject spurious traffic, possibly to hijack MAC 779 addresses. 781 This proposal does not, at this time, incorporate specific measures 782 against such attacks, relying instead on other traditional 783 mechanisms layered on top of IP. This section, instead, sketches 784 out some possible approaches to security in the VXLAN environment. 786 Traditional Layer 2 attacks by rogue end points can be mitigated by 787 limiting the management and administrative scope of who deploys and 788 manages VMs/gateways in a VXLAN environment. In addition, such 789 administrative measures may be augmented by schemes like 802.1X for 790 admission control of individual end points. Also, the use of the 791 UDP based encapsulation of VXLAN enables exploiting the 5 tuple 792 based ACLs (Access Control Lists) functionality in physical 793 switches. 795 Tunneled traffic over the IP network can be secured with traditional 796 security mechanisms like IPsec that authenticate and optionally 797 encrypt VXLAN traffic. This will, of course, need to be coupled with 798 an authentication infrastructure for authorized endpoints to obtain 799 and distribute credentials. 801 VXLAN overlay networks are designated and operated over the existing 802 LAN infrastructure. To ensure that VXLAN end points and their VTEPs 803 are authorized on the LAN, it is recommended that a VLAN be 804 designated for VXLAN traffic and the servers/VTEPs send VXLAN 805 traffic over this VLAN to provide a measure of security. 807 In addition, VXLAN requires proper mapping of VNIs and VM membership 808 in these overlay networks. It is expected that this mapping be done 809 and communicated to the management entity on the VTEP and the 810 gateways using existing secure methods. 812 9. IANA Considerations 814 A well-known UDP port (4789) has been assigned by IANA for VXLAN. 815 See Section 5 for discussion of the port number. 817 10. Conclusion 819 This document has introduced VXLAN, an overlay framework for 820 transporting MAC frames generated by VMs in isolated Layer 2 821 networks over an IP network. Through this scheme, it is possible to 822 stretch Layer 2 networks across Layer 3 networks. This finds use in 823 virtualized data center environments where Layer 2 networks may need 824 to span across the entire data center, or even between data centers. 826 11. References 828 11.1. Normative References 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, March 1997. 833 11.2. Informative References 835 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I., 836 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 837 Specification", RFC 4601, August 2006. 839 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and Vicisano, L., 840 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 841 5015, October 2007. 843 [RFC4541] Christensen, M., Kimball, K., and Solensky, F., 844 "Considerations for Internet Group Management Protocol (IGMP) 845 and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, 846 May 2006. 848 [nv03-Charter] Network Virtualization Working Overlays (nvo3) 849 charter, http://datatracker.ietf.org/wg/nvo3/charter/ 851 12. Acknowledgments 853 The authors wish to thank Ajit Sanzgiri for contributions to the 854 Security Considerations section and editorial inputs, Joseph Cheng, 855 Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva 856 Kollipara for their editorial reviews, inputs and comments. 858 Authors' Addresses 860 Mallik Mahalingam 862 Email: mallik_mahalingam@yahoo.com 864 Dinesh G. Dutt 865 Cumulus Networks 867 Email: ddutt.ietf@hobbesdutt.com 869 Kenneth Duda 870 Arista Networks 871 5470 Great America Parkway 872 Santa Clara, CA 95054 874 Email: kduda@aristanetworks.com 876 Puneet Agarwal 877 Broadcom Corporation 878 3151 Zanker Road 879 San Jose, CA 95134 881 Email: pagarwal@broadcom.com 882 Lawrence Kreeger 883 Cisco Systems, Inc. 884 170 W. Tasman Avenue 885 Palo Alto, CA 94304 887 Email: kreeger@cisco.com 889 T. Sridhar 890 VMware Inc. 891 3401 Hillview 892 Palo Alto, CA 94304 894 Email: tsridhar@vmware.com 896 Mike Bursell 897 Citrix Systems Research & Development Ltd. 898 Building 101 899 Cambridge Science Park 900 Milton Road 901 Cambridge CB4 0FY 902 United Kingdom 904 Email: mike.bursell@citrix.com 906 Chris Wright 907 Red Hat Inc. 908 1801 Varsity Drive 909 Raleigh, NC 27606 911 Email: chrisw@redhat.com