idnits 2.17.1 draft-mahalingam-dutt-dcops-vxlan-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 423 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 26 has weird spacing: '...t-Draft is s...' == Line 36 has weird spacing: '... at any ...' == Line 39 has weird spacing: '... The list ...' == Line 113 has weird spacing: '.... This is n...' == Line 126 has weird spacing: '... the indiv...' == (38 more instances...) -- The document date (October 16, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ECMP' is mentioned on line 121, but not defined == Unused Reference: 'RFC4601' is defined on line 836, but no explicit reference was found in the text == Unused Reference: 'RFC5015' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'RFC4541' is defined on line 844, 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 Storvisor 4 Intended Status: Experimental D. Dutt 5 Expires: February 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 October 16, 2013 20 VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over 21 Layer 3 Networks 22 draft-mahalingam-dutt-dcops-vxlan-05.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 November 8, 2013. 47 Copyright Notice 49 Copyright (c) 2013 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 Ranges........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....................................14 82 6.1. Inner VLAN Tag Handling..................................18 83 7. IETF Network Virtualization Overlays (nvo3) Working Group.....18 84 8. Security Considerations.......................................19 85 9. IANA Considerations...........................................20 86 10. Conclusion...................................................20 87 11. References...................................................20 88 11.1. Normative References....................................20 89 11.2. Informative References..................................20 90 12. Acknowledgments..............................................21 92 1. Introduction 94 Server virtualization has placed increased demands on the physical 95 network infrastructure. At a minimum, there is a need for more MAC 96 address table entries throughout the switched Ethernet network due 97 to potential attachment of hundreds of thousands of Virtual Machines 98 (VMs), each with its own MAC address. 100 Second, the VMs may be grouped according to their Virtual LAN 101 (VLAN). In a data center one might need thousands of VLANs to 102 partition the traffic according to the specific group that the VM 103 may belong to. The current VLAN limit of 4094 is inadequate in such 104 situations. A related requirement for virtualized environments is 105 having the Layer 2 network scale across the entire data center or 106 even between data centers for efficient allocation of compute, 107 network and storage resources. Using traditional approaches like 108 Spanning Tree Protocol (STP) for a loop free topology can result in 109 a large number of disabled links in such environments. 111 Another type of demand that is being placed on data centers is the 112 need to host multiple tenants, each with their own isolated network 113 domain. This is not economical to realize with dedicated 114 infrastructure, so network administrators opt to implement this over 115 a shared network. A concomitant problem is that each tenant may 116 independently assign MAC addresses and VLAN IDs leading to potential 117 duplication of these on the physical network. 119 The last scenario is the case where the network operator prefers to 120 use IP for interconnection of the physical infrastructure (e.g. to 121 achieve multipath scalability through Equal Cost Multipath [ECMP]) 122 while still preserving the Layer 2 model for inter-VM communication. 124 The scenarios described above lead to a requirement for an overlay 125 network. This overlay would be used to carry the MAC traffic from 126 the individual VMs in an encapsulated format over a logical 127 "tunnel". 129 This document details a framework termed Virtual eXtensible Local 130 Area Network (VXLAN) which provides such an encapsulation scheme to 131 address the various requirements specified above. 133 1.1. Acronyms & Definitions 135 ACL - Access Control List 137 ECMP - Equal Cost Multipath 139 IGMP - Internet Group Management Protocol 141 PIM - Protocol Independent Multicast 143 SPB - Shortest Path Bridging 145 STP - Spanning Tree Protocol 147 ToR - Top of Rack 149 TRILL - Transparent Interconnection of Lots of Links 151 VXLAN - Virtual eXtensible Local Area Network 153 VXLAN Segment - VXLAN Layer 2 overlay network over which VMs 155 communicate 157 VXLAN Overlay Network - another term for VXLAN Segment 159 VXLAN Gateway - an entity which forwards traffic between VXLAN 161 and non-VXLAN environments 163 VTEP - VXLAN Tunnel End Point - an entity which originates 164 and/or terminates VXLAN tunnels 166 VLAN - Virtual Local Area Network 168 VM - Virtual Machine 170 VNI - VXLAN Network Identifier (or VXLAN Segment ID) 172 2. Conventions used in this document 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC-2119 [RFC2119]. 178 In this document, these words will appear with that interpretation 179 only when in ALL CAPS. Lower case uses of these words are not to be 180 interpreted as carrying RFC-2119 significance. 182 3. VXLAN Problem Statement 184 This section details the problems that VXLAN is intended to address. 185 The focus is on the networking infrastructure within the data center 186 and the issues related to them. 188 3.1. Limitations imposed by Spanning Tree & VLAN Ranges 190 Current Layer 2 networks use the Spanning Tree Protocol (STP) to 191 avoid loops in the network due to duplicate paths. STP will turn off 192 links to avoid the replication and looping of frames. Some data 193 center operators see this as a problem with Layer 2 networks in 194 general since with STP they are effectively paying for more ports 195 and links than they can really use. In addition, resiliency due to 196 multipathing is not available with the STP model. Newer initiatives 197 like TRILL/Shortest Path Bridging (SPB) have been proposed to help 198 with multipathing and thus surmount some of the problems with STP. 199 STP limitations may also be avoided by configuring servers within a 200 rack to be on the same Layer 3 network with switching happening at 201 Layer 3 both within the rack and between racks. However, this is 202 incompatible with a Layer 2 model for inter-VM communication. 204 Another characteristic of Layer 2 data center networks is their use 205 of Virtual LANs (VLANs) to provide broadcast isolation. A 12 bit 206 VLAN ID is used in the Ethernet data frames to divide the larger 207 Layer 2 network into multiple broadcast domains. This has served 208 well for several data centers which require fewer than 4094 VLANs. 209 With the growing adoption of virtualization, this upper limit is 210 seeing pressure. Moreover, due to STP, several data centers limit 211 the number of VLANs that could be used. In addition, requirements 212 for multitenant environments accelerate the need for larger VLAN 213 limits, as discussed in Section 3.3. 215 3.2. Multitenant Environments 217 Cloud computing involves on demand elastic provisioning of resources 218 for multitenant environments. The most common example of cloud 219 computing is the public cloud, where a cloud service provider offers 220 these elastic services to multiple customers/tenants over the same 221 physical infrastructure. 223 Isolation of network traffic by tenant could be done via Layer 2 or 224 Layer 3 networks. For Layer 2 networks, VLANs are often used to 225 segregate traffic - so a tenant could be identified by its own VLAN, 226 for example. Due to the large number of tenants that a cloud 227 provider might service, the 4094 VLAN limit is often inadequate. In 228 addition, there is often a need for multiple VLANs per tenant, which 229 exacerbates the issue. 231 Another use case is cross pod expansion. A pod typically consists of 232 one or more racks of servers with associated network and storage 233 connectivity. Tenants may start off on a pod and, due to expansion, 234 require servers/VMs on other pods, especially in the case when 235 tenants on the other pods are not fully utilizing all their 236 resources. This use case requires a "stretched" Layer 2 environment 237 connecting the individual servers/VMs. 239 Layer 3 networks are not a comprehensive solution for multi tenancy 240 either. Two tenants might use the same set of Layer 3 addresses 241 within their networks which requires the cloud provider to provide 242 isolation in some other form. Further, requiring all tenants to use 243 IP excludes customers relying on direct Layer 2 or non-IP Layer 3 244 protocols for inter VM communication. 246 3.3. Inadequate Table Sizes at ToR Switch 248 Today's virtualized environments place additional demands on the MAC 249 address tables of Top of Rack (ToR) switches which connect to the 250 servers. Instead of just one MAC address per server link, the ToR 251 now has to learn the MAC addresses of the individual VMs (which 252 could range in the 100s per server). This is a requirement since 253 traffic from/to the VMs to the rest of the physical network will 254 traverse the link between the server and the switch. A typical ToR 255 switch could connect to 24 or 48 servers depending upon the number 256 of its server facing ports. A data center might consist of several 257 racks, so each ToR switch would need to maintain an address table 258 for the communicating VMs across the various physical servers. This 259 places a much larger demand on the table capacity compared to non- 260 virtualized environments. 262 If the table overflows, the switch may stop learning new addresses 263 until idle entries age out, leading to significant flooding of 264 subsequent unknown destination frames. 266 4. Virtual eXtensible Local Area Network (VXLAN) 268 VXLAN (Virtual eXtensible Local Area Network) addresses the above 269 requirements of the Layer 2 and Layer 3 data center network 270 infrastructure in the presence of VMs in a multitenant environment. 271 It runs over the existing networking infrastructure and provides a 272 means to "stretch" a Layer 2 network. In short, VXLAN is a Layer 2 273 overlay scheme over a Layer 3 network. Each overlay is termed a 274 VXLAN segment. Only VMs within the same VXLAN segment can 275 communicate with each other. Each VXLAN segment is scoped through a 276 24 bit segment ID, hereafter termed the VXLAN Network Identifier 277 (VNI). This allows up to 16M VXLAN segments to coexist within the 278 same administrative domain. 280 The VNI scopes the inner MAC frame originated by the individual VM. 281 Thus, you could have overlapping MAC addresses across segments but 282 never have traffic "cross over" since the traffic is isolated using 283 the VNI qualifier. This qualifier is in an outer header envelope 284 over the inner MAC frame originated by the VM. In the following 285 sections, the term "VXLAN segment" is used interchangeably with the 286 term "VXLAN overlay network". 288 Due to this encapsulation, VXLAN could also be termed a tunneling 289 scheme to overlay Layer 2 networks on top of Layer 3 networks. The 290 tunnels are stateless, so each frame is encapsulated according to a 291 set of rules. The end point of the tunnel (VTEP) discussed in the 292 following sections is located within the hypervisor on the server 293 which houses the VM. Thus, the VNI and VXLAN related tunnel/outer 294 header encapsulation are known only to the VTEP - the VM never sees 295 it (see Figure 1). Note that it is possible that VTEPs could also be 296 on a physical switch or physical server and could be implemented in 297 software or hardware. One use case where the VTEP is a physical 298 switch is discussed in Section 6 on VXLAN deployment scenarios. 300 The following sections discuss typical traffic flow scenarios in a 301 VXLAN environment using one type of control scheme - data plane 302 learning. Here, the association of VM's MAC to VTEP's IP is 303 discovered via source learning. Multicast is used for carrying 304 unknown destination, broadcast and multicast frames. 306 In addition to a learning based control plane, there are other 307 schemes possible for the distribution of the VTEP IP to VM MAC 308 mapping information. Options could include a central 309 authority/directory based lookup by the individual VTEPs, 310 distribution of this mapping information to the VTEPs by the central 311 authority, and so on. These are sometimes characterized as push and 312 pull models respectively. This draft will focus on the data plane 313 learning scheme as the control plane for VXLAN. 315 4.1. Unicast VM to VM communication 317 Consider a VM within a VXLAN overlay network. This VM is unaware of 318 VXLAN. To communicate with a VM on a different host, it sends a MAC 319 frame destined to the target as before. The VTEP on the physical 320 host looks up the VNI to which this VM is associated. It then 321 determines if the destination MAC is on the same segment and if 322 there is a mapping of the destination MAC address to 323 the remote VTEP. If so, an outer header comprising an outer MAC, 324 outer IP address and VXLAN header (see Figure 1 in Section 5 for 325 frame format) are inserted in front of the original MAC frame. The 326 final packet is transmitted out to the destination. This is the IP 327 address of the remote VTEP connecting the destination VM 328 (represented by the inner MAC destination address). 330 Upon reception, the remote VTEP verifies the validity of the VNI and 331 if there is a VM on that VNI using a MAC address that matches the 332 inner destination MAC address. If so, the packet is stripped of its 333 outer header and passed on to the destination VM. The destination VM 334 never knows about the VNI or that the frame was transported with a 335 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 below. Broadcast frames are used 346 but are encapsulated within a multicast packet, as detailed in the 347 next section. 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. In addition, use of multicast routing 371 protocols like Protocol Independent Multicast - Sparse Mode (PIM-SM) 372 will provide efficient multicast trees within the Layer 3 network. 374 The VTEP will use (*,G) joins. This is needed as the set of VXLAN 375 tunnel sources is unknown and may change often, as the VMs come 376 up/go down across different hosts. A side note here is that since 377 each VTEP can act as both the source and destination for multicast 378 packets, a protocol like PIM-bidir would be more efficient. 380 The destination VM sends a standard ARP response using IP unicast. 381 This frame will be encapsulated back to the VTEP connecting the 382 originating VM using IP unicast VXLAN encapsulation. This is 383 possible since the mapping of the ARP response's destination MAC to 384 the VXLAN tunnel end point IP was learned earlier through the ARP 385 request. 387 Another point to note is that multicast frames and "unknown MAC 388 destination" frames are also sent using the multicast tree, similar 389 to the broadcast frames. 391 4.3. Physical Infrastructure Requirements 393 When IP multicast is used within the network infrastructure, a 394 multicast routing protocol like PIM-SM can be used by the individual 395 Layer 3 IP routers/switches within the network. This is used to 396 build efficient multicast forwarding trees so that multicast frames 397 are only sent to those hosts which have requested to receive them. 399 Similarly, there is no requirement that the actual network 400 connecting the source VM and destination VM should be a Layer 3 401 network - VXLAN can also work over Layer 2 networks. In either case, 402 efficient multicast replication within the Layer 2 network can be 403 achieved using IGMP snooping. 405 5. VXLAN Frame Format 407 The VXLAN frame format is shown below. Parsing this from the bottom, 408 there is an inner MAC frame with its own Ethernet header with 409 source, destination MAC addresses along with the Ethernet type plus 410 an optional VLAN. One use case of the inner VLAN tag is with VM 411 based VLAN tagging in a virtualized environment. See Section 6 for 412 further details of inner VLAN tag handling. 414 The inner MAC frame is encapsulated with the following four headers 415 (starting from the innermost header): 417 O VXLAN Header: This is an 8 byte field which has: 419 o Flags (8 bits)- where the I flag MUST be set to 1 for a valid 420 VXLAN Network ID (VNI). The other 7 bits (designated "R") are 421 reserved fields and MUST be set to zero. 423 o VXLAN Segment ID/VXLAN Network Identifier (VNI) - this is a 24 424 bit value used to designate the individual VXLAN overlay network 425 on which the communicating VMs are situated. VMs in different 426 VXLAN overlay networks cannot communicate with each other. 428 o Reserved fields (24 bits and 8 bits) - MUST be set to zero. 430 O Outer UDP Header: This is the outer UDP header with a source 431 port provided by the VTEP and the destination port being a well- 432 known UDP port. IANA has assigned the value 4789 for the VXLAN UDP 433 port and this value SHOULD be used by default as the destination UDP 434 port. Some early implementations of VXLAN have used other values 435 for the destination port. To enable interoperability with these 436 implementations, the destination port SHOULD be configurable. It is 437 recommended that the source port number be calculated using a hash 438 of fields from the inner packet - one example being a hash of the 439 inner Ethernet frame`s headers. This is to enable a level of entropy 440 for ECMP/load balancing of the VM to VM traffic across the VXLAN 441 overlay. 443 The UDP checksum field SHOULD be transmitted as zero. When a packet 444 is received with a UDP checksum of zero, it MUST be accepted for 445 decapsulation. Optionally, if the encapsulating endpoint includes a 446 non-zero UDP checksum, it MUST be correctly calculated across the 447 entire packet including the IP header, UDP header, VXLAN header and 448 encapsulated MAC frame. When a decapsulating endpoint receives a 449 packet with a non-zero checksum it MAY choose to verify the 450 checksum value. If it chooses to perform such verification, and the 451 verification fails, the packet MUST be dropped. If the 452 decapsulating destination chooses not to perform the verification, 453 or performs it successfully, the packet MUST be accepted for 454 decapsulation. 456 O Outer IP Header: This is the outer IP header with the source IP 457 address indicating the IP address of the VTEP over which the 458 communicating VM (as represented by the inner source MAC address) is 459 running. The destination IP address can be a unicast or multicast 460 IP address (see Sections 4.1 and 4.2). When it is a unicast IP 461 address, it represents the IP address of the VTEP connecting the 462 communicating VM as represented by the inner destination MAC 463 address. For multicast destination IP addresses, please refer to the 464 scenarios detailed in Section 4.2. 466 O Outer Ethernet Header (example): Figure 1 is an example of an 467 inner Ethernet frame encapsulated within an outer Ethernet + IP + 468 UDP + VXLAN header. The outer destination MAC address in this frame 469 may be the address of the target VTEP or of an intermediate Layer 3 470 router. The outer VLAN tag is optional. If present, it may be used 471 for delineating VXLAN traffic on the LAN. 473 0 1 2 3 474 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 476 Outer Ethernet Header: | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Outer Destination MAC Address | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Outer Destination MAC Address | Outer Source MAC Address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Outer Source MAC Address | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Optional Ethertype = C-Tag 802.1Q | Outer.VLAN Tag Information | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Ethertype = 0x0800 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Outer IPv4 Header: 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |Version| IHL |Type of Service| Total Length | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Identification |Flags| Fragment Offset | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Time to Live |Protocl=17(UDP)| Header Checksum | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Outer Source IPv4 Address | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Outer Destination IPv4 Address | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Outer UDP Header: 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Source Port = xxxx | Dest Port = VXLAN Port | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | UDP Length | UDP Checksum | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 VXLAN Header: 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 |R|R|R|R|I|R|R|R| Reserved | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | VXLAN Network Identifier (VNI) | Reserved | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 515 Inner Ethernet Header: | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Inner Destination MAC Address | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Inner Destination MAC Address | Inner Source MAC Address | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Inner Source MAC Address | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Optional Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Payload: 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Ethertype of Original Payload | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 529 | Original Ethernet Payload | 530 | | 531 | (Note that the original Ethernet Frame's FCS is not included) | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Frame Check Sequence: 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 1 VXLAN Frame Format with IPv4 Outer Header 540 The frame format above shows tunneling of Ethernet frames using IPv4 541 for transport. Use of VXLAN with IPv6 transport is detailed below. 543 0 1 2 3 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 546 Outer Ethernet Header: | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Outer Destination MAC Address | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Outer Destination MAC Address | Outer Source MAC Address | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Outer Source MAC Address | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Optional Ethertype = C-Tag 802.1Q| Outer.VLAN Tag Information | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Ethertype = 0x86DD | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Outer IPv6 Header: 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |Version| Traffic Class | Flow Label | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 + + 566 | | 567 + Outer Source IPv6 Address + 568 | | 569 + + 570 | | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | 573 + + 574 | | 575 + Outer Destination IPv6 Address + 576 | | 577 + + 578 | | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Outer UDP Header: 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Source Port = xxxx | Dest Port = VXLAN Port | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | UDP Length | UDP Checksum | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 VXLAN Header: 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |R|R|R|R|I|R|R|R| Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | VXLAN Network Identifier (VNI) | Reserved | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Inner Ethernet Header: 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Inner Destination MAC Address | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Inner Destination MAC Address | Inner Source MAC Address | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Inner Source MAC Address | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Optional Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Payload: 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Ethertype of Original Payload | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 609 | Original Ethernet Payload | 610 | | 611 | (Note that the original Ethernet Frame's FCS is not included) | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Frame Check Sequence: 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | New FCS (Frame Check Sequence) for Outer Ethernet Frame | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 2 VXLAN Frame Format with IPv6 Outer Header 620 6. VXLAN Deployment Scenarios 622 VXLAN is typically deployed in data centers on virtualized hosts, 623 which may be spread across multiple racks. The individual racks may 624 be parts of a different Layer 3 network or they could be in a single 625 Layer 2 network. The VXLAN segments/overlay networks are overlaid on 626 top of these Layer 2 or Layer 3 networks. 628 Consider Figure 3 below depicting two virtualized servers attached 629 to a Layer 3 infrastructure. The servers could be on the same rack, 630 or on different racks or potentially across data centers within the 631 same administrative domain. There are 4 VXLAN overlay networks 632 identified by the VNIs 22, 34, 74 and 98. Consider the case of VM1-1 633 in Server 1 and VM2-4 on Server 2 which are on the same VXLAN 634 overlay network identified by VNI 22. The VMs do not know about the 635 overlay networks and transport method since the encapsulation and 636 decapsulation happen transparently at the VTEPs on Servers 1 and 2. 637 The other overlay networks and the corresponding VMs are: VM1-2 on 638 Server 1 and VM2-1 on Server 2 both on VNI 34, VM1-3 on Server 1 and 639 VM2-2 on Server 2 on VNI 74, and finally VM1-4 on Server 1 and VM2-3 640 on Server 2 on VNI 98. 642 +------------+-------------+ 643 | Server 1 | 644 | +----+----+ +----+----+ | 645 | |VM1-1 | |VM1-2 | | 646 | |VNI 22 | |VNI 34 | | 647 | | | | | | 648 | +---------+ +---------+ | 649 | | 650 | +----+----+ +----+----+ | 651 | |VM1-3 | |VM1-4 | | 652 | |VNI 74 | |VNI 98 | | 653 | | | | | | 654 | +---------+ +---------+ | 655 | Hypervisor VTEP (IP1) | 656 +--------------------------+ 657 | 658 | 659 | 660 | 661 | 662 | 663 | +-------------+ 664 | | Layer 3 | 665 |---| Network | 666 | | 667 +-------------+ 668 | 669 | 670 +------------+ 671 | 672 +------------+-------------+ 673 | Server 2 | 674 | +----+----+ +----+----+ | 675 | |VM2-1 | |VM2-2 | | 676 | |VNI 34 | |VNI 74 | | 677 | | | | | | 678 | +---------+ +---------+ | 679 | | 680 | +----+----+ +----+----+ | 681 | |VM2-3 | |VM2-4 | | 682 | |VNI 98 | |VNI 22 | | 683 | | | | | | 684 | +---------+ +---------+ | 685 | Hypervisor VTEP (IP2) | 686 +--------------------------+ 688 Figure 3 VXLAN Deployment - VTEPs across a Layer 3 Network 690 One deployment scenario is where the tunnel termination point is a 691 physical server which understands VXLAN. Another scenario is where 692 nodes on a VXLAN overlay network need to communicate with nodes on 693 legacy networks which could be VLAN based. These nodes may be 694 physical nodes or virtual machines. To enable this communication, a 695 network can include VXLAN gateways (see Figure 4 below with a switch 696 acting as a VXLAN gateway) which forward traffic between VXLAN and 697 non-VXLAN environments. 699 Consider Figure 4 for the following discussion. For incoming frames 700 on the VXLAN connected interface, the gateway strips out the VXLAN 701 header and forwards to a physical port based on the destination MAC 702 address of the inner Ethernet frame. Decapsulated frames with the 703 inner VLAN ID SHOULD be discarded unless configured explicitly to be 704 passed on to the non-VXLAN interface. In the reverse direction, 705 incoming frames for the non-VXLAN interfaces are mapped to a 706 specific VXLAN overlay network based on the VLAN ID in the frame. 707 Unless configured explicitly to be passed on in the encapsulated 708 VXLAN frame, this VLAN ID is removed before the frame is 709 encapsulated for VXLAN. 711 These gateways which provide VXLAN tunnel termination functions 712 could be ToR/access switches or switches higher up in the data 713 center network topology - e.g. core or even WAN edge devices. The 714 last case (WAN edge) could involve a Provider Edge (PE) router which 715 terminates VXLAN tunnels in a hybrid cloud environment. Note that in 716 all these instances, the gateway functionality could be implemented 717 in software or hardware. 719 +---+-----+---+ +---+-----+---+ 720 | Server 1 | | Non VXLAN | 721 (VXLAN enabled)<-----+ +---->| server | 722 +-------------+ | | +-------------+ 723 | | 724 +---+-----+---+ | | +---+-----+---+ 725 |Server 2 | | | | Non VXLAN | 726 (VXLAN enabled)<-----+ +---+-----+---+ +---->| server | 727 +-------------+ | |Switch acting| | +-------------+ 728 |---| as VXLAN |-----| 729 +---+-----+---+ | | Gateway | 730 | Server 3 | | +-------------+ 731 (VXLAN enabled)<-----+ 732 +-------------+ | 733 | 734 +---+-----+---+ | 735 | Server 4 | | 736 (VXLAN enabled)<-----+ 737 +-------------+ 738 Figure 4 VXLAN Deployment - VXLAN Gateway 740 6.1. Inner VLAN Tag Handling 742 Inner VLAN Tag Handling in VTEP and VXLAN Gateway should conform to 743 the following: 745 Decapsulated VXLAN frames with the inner VLAN tag SHOULD be 746 discarded unless configured otherwise. On the encapsulation side, a 747 VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless 748 configured otherwise. When a VLAN-tagged packet is a candidate for 749 VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag 750 unless configured otherwise. 752 7. IETF Network Virtualization Overlays (nvo3) Working Group 754 The IETF has chartered the Network Virtualization Overlays (nvo3) 755 Working Group (WG) under the Routing Area. The charter 756 (http://datatracker.ietf.org/wg/nvo3/charter/) indicates that the WG 757 will consider the multi tenancy approaches residing at the network 758 layer. The WG will provide a problem statement, architectural 759 framework and requirements for the control and data plane for such 760 network virtualization overlay schemes. Operations, Administration 761 and Management (OA&M) requirements for the nvo3 are also within the 762 scope of the WG. The active Internet drafts being considered by the 763 working group are at http://datatracker.ietf.org/wg/nvo3/. This 764 document on VXLAN addresses the requirements outlined in the nvo3 WG 765 charter. It outlines the data plane requirements as well as the 766 method to establish the forwarding entries in each VTEP. 768 8. Security Considerations 770 Traditionally, layer 2 networks can only be attacked from 'within' 771 by rogue endpoints - either by having inappropriate access to a LAN 772 and snooping on traffic or by injecting spoofed packets to 'take 773 over' another MAC address or by flooding and causing denial of 774 service. A MAC-over-IP mechanism for delivering Layer 2 traffic 775 significantly extends this attack surface. This can happen by rogues 776 injecting themselves into the network by subscribing to one or 777 more multicast groups that carry broadcast traffic for VXLAN 778 segments and also by sourcing MAC-over-UDP frames into the transport 779 network to inject spurious traffic, possibly to hijack MAC 780 addresses. 782 This document does not, at this time, incorporate specific measures 783 against such attacks, relying instead on other traditional 784 mechanisms layered on top of IP. This section, instead, sketches 785 out some possible approaches to security in the VXLAN environment. 787 Traditional Layer 2 attacks by rogue end points can be mitigated by 788 limiting the management and administrative scope of who deploys and 789 manages VMs/gateways in a VXLAN environment. In addition, such 790 administrative measures may be augmented by schemes like 802.1X for 791 admission control of individual end points. Also, the use of the 792 UDP based encapsulation of VXLAN enables exploiting the 5 tuple 793 based ACLs (Access Control Lists) functionality in physical 794 switches. 796 Tunneled traffic over the IP network can be secured with traditional 797 security mechanisms like IPsec that authenticate and optionally 798 encrypt VXLAN traffic. This will, of course, need to be coupled with 799 an authentication infrastructure for authorized endpoints to obtain 800 and distribute credentials. 802 VXLAN overlay networks are designated and operated over the existing 803 LAN infrastructure. To ensure that VXLAN end points and their VTEPs 804 are authorized on the LAN, it is recommended that a VLAN be 805 designated for VXLAN traffic and the servers/VTEPs send VXLAN 806 traffic over this VLAN to provide a measure of security. 808 In addition, VXLAN requires proper mapping of VNIs and VM membership 809 in these overlay networks. It is expected that this mapping be done 810 and communicated to the management entity on the VTEP and the 811 gateways using existing secure methods. 813 9. IANA Considerations 815 A well-known UDP port (4789) has been assigned by IANA for VXLAN. 816 See Section 5 for discussion of the port number. 818 10. Conclusion 820 This document has introduced VXLAN, an overlay framework for 821 transporting MAC frames generated by VMs in isolated Layer 2 822 networks over an IP network. Through this scheme, it is possible to 823 stretch Layer 2 networks across Layer 3 networks. This finds use in 824 virtualized data center environments where Layer 2 networks may need 825 to span across the entire data center, or even between data centers. 827 11. References 829 11.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 11.2. Informative References 836 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and Kouvelas, I., 837 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 838 Specification", RFC 4601, August 2006. 840 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and Vicisano, L., 841 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 842 5015, October 2007. 844 [RFC4541] Christensen, M., Kimball, K., and Solensky, F., 845 "Considerations for Internet Group Management Protocol (IGMP) 846 and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, 847 May 2006. 849 [nv03-Charter] Network Virtualization Working Overlays (nvo3) 850 charter, http://datatracker.ietf.org/wg/nvo3/charter/ 852 12. Acknowledgments 854 The authors wish to thank Ajit Sanzgiri for contributions to the 855 Security Considerations section and editorial inputs, Joseph Cheng, 856 Margaret Petrus, Milin Desai, Nial de Barra, Jeff Mandin and Siva 857 Kollipara for their editorial reviews, inputs and comments. 859 Authors' Addresses 861 Mallik Mahalingam 862 Storvisor 863 333 W.El Camino Real 864 Sunnyvale, CA 94087 866 Email: mallik_mahalingam@yahoo.com 868 Dinesh G. Dutt 869 Cumulus Networks 870 140C S.Whisman Road 871 Mountain View, CA 94041 873 Email: ddutt.ietf@hobbesdutt.com 875 Kenneth Duda 876 Arista Networks 877 5470 Great America Parkway 878 Santa Clara, CA 95054 880 Email: kduda@aristanetworks.com 882 Puneet Agarwal 883 Broadcom Corporation 884 3151 Zanker Road 885 San Jose, CA 95134 887 Email: pagarwal@broadcom.com 888 Lawrence Kreeger 889 Cisco Systems, Inc. 890 170 W. Tasman Avenue 891 Palo Alto, CA 94304 893 Email: kreeger@cisco.com 895 T. Sridhar 896 VMware Inc. 897 3401 Hillview 898 Palo Alto, CA 94304 900 Email: tsridhar@vmware.com 902 Mike Bursell 903 Citrix Systems Research & Development Ltd. 904 Building 101 905 Cambridge Science Park 906 Milton Road 907 Cambridge CB4 0FY 908 United Kingdom 910 Email: mike.bursell@citrix.com 912 Chris Wright 913 Red Hat Inc. 914 1801 Varsity Drive 915 Raleigh, NC 27606 917 Email: chrisw@redhat.com