Independent Submission M. Mahalingam Request for Comments: 7348 Storvisor Category: Informational D. Dutt ISSN: 2070-1721 Cumulus Networks K. Duda Arista P. Agarwal Broadcom L. Kreeger cisco 7. sridnar vuware M. Bursell Intel C. Wright Red Fat August 2014 Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks Abstract This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within Virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This meno documents the deployed VXLAN protocol for the benefit of the Internet community. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational puzposes. This is 2 contribution to the RFC Series, independently of any ether REC stream. he REC Editor has chosen to publish this document at its discretion and makes no statement about ite value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http: //www.rfe~ed: tor.org/info/rfc7348. Mahalingam, et al. informational [page 1]REC 7348 VxLAN August 2014 Copyright Wot. Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http: //trustee.ietf-org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect te this document. Table of Contents 1. Introduction .......eeeeeee eee 1.1. Acronyms and Definitions 2. Conventions Used in This Document 3. VXIAN Problem Statement : 3.1, Limitations Imposed by Spanning Tree and VLAN Ranges 11. Multi-tenant Environments Inadequate Table Sizes at TOR Switch Unicast VH-to-vit Communication St Broadcast Communication and Mapping to Multi Physical Infrastructure Requirements 5. VALAN Frame Format 6. VXLAN Deployment scenarios 6.1. Inner VLAN Tag Handling 7. Security Considerations TANA Considerations References 9.1. Normative References 9.2. Informative References 10. Acknowledgments aw Mahalingam, et al. Informational, [Page 21REC 7348 VxLAN August 2014 Le Introduction Server virtualization has placed increased demands on the physical network infrastructure. A physical server now has multiple Virtual Machines (VMs) each with its own Media Access Control (MAC) address. This requires larger MAC address tables in the switched Ethernet network due to potential attachment ef and communication among hundreds of thousands of Vs. Th the case when the Ws in a data center are grouped according to their Virtual LAN (VLAN), one might need thousands of VLANs to partition the traffic according to the specific group to which the VM may belong. Tae current VLAN limit of 4094 is inadequate in such situations. Data centers are often required to host multiple tenants, each with their own isolated network domain, Since it is not economical to realize this with dedicated infrastructure, network administrators opt to implement isolation over a shared network. In such scenarios, a common problem is that each tenant may independently assign MAC addresses and VLAN 2Ds leading to potential duplication of these on the physical network. An important requirement for virtualized environments using a Layer 2 physical infrastructure is having the Layer 2 network scale across the entire data center or even between data centers for efficient allocation of compute, network, and storage resources. In such networks, using traditional approaches like the Spanning Tree Protocol (STP) for a loop-free topology can result in a large number of disabled links. ‘The last scenario is the case where the network operator prefers to use IP for interconnection of the physical infrastructure (e.g., to achieve multipath scalability through Equal-Cost Multipath (ECMP), thus avoiding disabled links). Even in such environments, there is a need to preserve the Layer 2 model for inter-VM communication. ‘The scenarios described above lead to a requirement for an overlay network. This overiay is used to carry the MAC traffic from the individual VMs in an encapsulated format over a logical "tunnel". ‘This document detaiis a framework termed "Virtual eXtensibie Local Area Network (VKLAN)" that provides such an encapsulation scheme to address the various requirements specified above. This memo documents the deployed VxLAN protocol for the benefit of the Internet community. Mahalingam, et al. Informational, [Page 3)REC 7348 VxLAN August 2014 1.1, Acronyms and Definitions ach Access Control List ECMP —-Equal-Cost Multipath IGMP Internet Group Management Protocol ran Internet Header Length wru Maximum Transmission Unit Pi Protocol Independent Mult SPB Shortest Path Bridging sre Spanning Tree Protocol TOR Top of Rack TRILL Transparent Interconnection of Lets of Links VbaN Virtual hocal Area Network vy Virtual Machine vwt VXLAN Network Identifier (or VALAN Segment TD) VIE -VXLAN Tunnel End Point. Rn entity that originates and/or terminates VxLAN tunnels VKIAN Virtual eXtensible Local Area Network VALAN Segment VXLAN Layer 2 overlay network over which VMs communicate VXLAN Gateway an entity that forwards traffic between VXLANS 2. Conventions Used in This Document ‘The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (RFC2119). Mahalingam, et al. Informational, [Page 4]REC 7348 VxLAN August 2014 VXLAN Problem Statement This section provides further details on the areas that VXLAN is intended to address. The focus is on the networking infrastructure within the data center and the issues related to them. 3.1, Limitations Imposed by Spanning Tree and VLAN Ranges Current Layer 2 networks use the IEEE 802.1D Spanning Tree Protocol (STP) [802.1D] to avoid loops in the network due to duplicate paths. STP blocks the use of links to avold the replication and looping of frames. Some data center operators see this as a problem with Layer 2 networks in general, since with STP they are effectively paying for more ports and links than they can really use. In addition, resiliency due to multipathing is not available with the STP model. Newer initiatives, such as TRILL [RFC6325] and SPE [802.1aq], have been proposed to he2p with multipathing and surmount some of the problems with STP. STP limitations may also be avoided by configuring servers within a rack to be on the same Layer 3 network, with switching happening at Layer 3 both within the rack and between racks. However, this is incompatible with a Layer 2 model for inter- Ye communication. A key characteristic of Layer 2 data center networks is their use of Virtual LANs (VLANs) to provide broadcast isolation. A 72-bit VLAN ID is used in the Ethernet data frames to divide the larger Layer 2 network into multiple broadcast domains. This has served well for many data centers that require fewer than 4094 VLANs. With the growing adoption of virtualization, this upper limit is seeing pressure. Moreover, due to STP, several data centers limit the number of VLANs that could be used. In addition, requirements for multi-tenant environments accelerate the need for larger VLAN linits, as discussed in Section 3.3. 3.2. Multi-tenant Environments Cloud computing involves on-demand elastic provisioning of resources for multi-tenant environments. The most common example of cloud computing is the public cloud, where a cloud service provider offers these elastic services to multiple customers/tenants over the same physical infrastructure. Isolation of network traffic by a tenant could be done via Layer 2 or Layer 3 networks. For Layer 2 networks, VLANs are often used to segregate traffic -- so a tenant could be identified by its own VLAN, for example. Due to the large number of tenants that a cloud Mahalingam, et al. Informational, [Page 9]REC 7348 VxLAN August 2014 provider might service, the 4094 VIAN limit is often inadequate. In addition, there is often a need for multiple VLANs per tenant, which exacerbates the issue. A related use case is cross-pod expansion. A pod typically consists of one or more racks of servers with associated network and storage connectivity. Tenants may stazt off on a pod and, due to expansion, require servers/VMs on other pods, especially in the case when tenants on the other pods are not fully utilizing all their resources. This use case requires a "stretched" Layer 2 environment connecting the individual servers/vis. Layer 3 networks are not a comprehensive solution for multi-tenancy either, Two tenants might use the same set of Layer 3 addresses within their networks, which requires the cloud provider to provide isolation in some other form. further, requiring all tenants to use IP excludes customers relying on direct Layer 2 or non-IP Layer 3 protocols for inter VM communication. 3.3. Inadequate Table Sizes at ToR Switch Today's virtualized environments place additional demands on the MAC address tables of Top-of-Rack (ToR) switches that connect to the servers. Instead of just one MAC address per server link, the ToR now has to learn the WAC addresses of the individual VMs (which could range in the hundreds per server). This is needed because traffic to/from the VMs to the rest of the physical network will traverse the link between the server and the gwiteh. A typical ToR switch could connect to 24 or 48 servers depending upon the number of its server- facing ports. A data center might consist of several racks, so each ToR switch would need to maintain an address table for the communicating VMs across the various physical servers. This places a much larger demand on the table capacity compared to non-virtualized environments. If the table overflows, the switch may stop learning new addresses until idle entries age out, leading to significant flooding of subseuent unknown destination frames. 4. VKTAN VALAN (Virtual eXtensible Local Area Network) addresses the above requirements of the Layer 2 and Layer 3 data center network infrastructure in the presence of VWs in a multi-tenant environment. It runs over the existing networking infrastructure and provides a means te "stretch" a Layer 2 network. In short, VXLAN is a Layer 2 overlay scheme on a Layer 3 network. Each overlay is termed a VELAN segment. Only VMs within the same VXLAN segment can communicate with Mahalingam, et al. Informational, [Page 6]REC 7348 VxLAN August 2014 each other. Hach VXLAN segment is identified through a 24-bit segment ID, termed the "VKLAN Network Identifier (VNI)". This allows up to 16 M VXLAN segments to coexist within the same administrative domain. The VWI identifies the scope of the inner MAC frame originated by the individual VM. Thus, you could have overlapping MAC addresses across segments but never have traffic “cross over" since the traffic is isolated using the VNI. The VNI is in an outer header that encapsulates the ‘nner MAC frame originated by the VM. Tn the following sections, the term "VXLAN segment" is used interchangeably with the term "VXLAN overlay network". Due to this encapsulation, VXLAN could also be called a tunneling scheme to overlay Layer 2 networks on top of Layer 3 networks. The tunnels are stateless, so each frame is encapsulated according to a set of rules. The end point of the tunnel (VXLAN Tunnel End Point or VTEP) discussed in the following sections is located within the hypervisor on the server that hosts the VM. Thus, the VNI- and VALAN-related tunne? / outer header encapsulation are known only to the VIEP -- the VM never sees it (see Figure 1). Note that it is possible that VTEPs could also be on a physical switch or physical server and could be implemented in software or hardware. One use case where the VIEP le a physical ewitch is discussed in Section 6 on VXLAN deployment scenarios. The following sections discuss typical traffic flow scenarios ina VXLAN environment using one Lype of control scheme -- data plane learning. Here, the association of VMs MAC to VIEP’s IP address is discovered via Source-address learning. Multicast is used for carrying unknown Gestination, broadcast, and multicast frames. In addition to a learning-based control plane, there are other schemes possible for the distribution of the VTEP IP to VM MAC mapping information. Options could include a central authority-/directory-based lookup by the individual VTEPs, distribution of this mapping information to the VTBPs by the central authority, and so on. ‘These aze sometimes characterized as push and pull models, respectively. This document will focus on the data plane learning scheme as the control plane for VXTAN. 4.1. Unicast VM-to-VM Communication Consider a VM within a VKLAN overlay network. This VM is unaware of VALAN. To communicate with a VM on a different host, it sends a MAC frame destined to the target as normal. The VPEP on’ the physical host looks up the VNI to which this VM is associated. It then determines if the destination MAC is on the same segment and if there Mahalingam, et al. Informational, [Page 7REC 7348 VxLAN August 2014 is a mapping of the destination MAC address to the remote VTEP. Tf sc, an outer header comprising an outer MAC, outer IP header, and VXLAN header (see Figure 1 in Section 5 for frame format) are prepended to the original MAC frame. The encapsulated packet is forwarded towards the remote VTEP. Upon reception, the remote VTE? verifies the validity of the VNI and whether or not there is a VM on that VNI using a MAC address that matches the inner destination MAC address. If so, the packet is stripped of its encapsulating headers and passed on to the destination VM. The destination VM never knows about the VNT or that the frame was transported with @ VXIAN encapsulation. In addition to forwarding the packet to the destination WM, the remote VIEP learns the mapping from inner source MAC to outer source IP address. Tt stores this mapping in a table so that when the destination VM sends a response packet, there is no need for an “unknown destination” flooding of the response packet. Determining the MAC address of the destination VM prior to the transmission by the source VM is performed as with non-VXLAN environments except as described in Section 4.2. Broadcast frames are used but are encapsulated within a multicast packet, as detailed in the Section 4.2. 4.2, Broadcast Communication and Mapping to Multicast Consider the VM on the source host attempting to communicate with the destination VM using IP. Assuming thal they are both on the same subnet, the VM sends out an Address Resolution 2rotocol (ARE) broadcast frame. Tn the non-VXLAN environment, this frame would be sent out using MAC broadcast across all switches carrying that VIAN. With VXLAN, a header including the VXLAN VNI is inserted at the beginning of the packet along with the IP header and UDP header. However, this broadcast packet is sent out to the IP multicast group on which that VXLAN overlay network is realized. To effect this, we need to have a mapping between the VXLAN VNI and the IP multicast group that it will use. This mapping is cone at the management layer and provided to the individual VTRPs through a management. channe>. Using this mapping, the VZEP can provide IGMP menbership reports to the upstream switch/router to join/leave the VMLAN-related IP multicast groups as needed. This will enable pruning of the leaf nodes for specific multicast traffic addresses based on whether a member is available on this host using the specific multicast address (see [RFC4541]}. In addition, use of Mahalingam, et al. Informational, [Page 8]REC 7348 VxLAN August 2014 multicast routing protocols like Protocol Independent Multicast - Sparse Mode (PIM-SM see [RFC4601]) will provide efficient multicast trees within the Layer 3 network. ‘The VPEP will use (*,G) joins. This is needed as the set of VXLAN tunnel sources is unknown and may change often, as the VMs cone up / go down across different hosts. A side note here is that since each VIEP can act as both the source and destination for multicast packets, a protocol like bidirectional PIM (BIDIR-PIM ~~ see [RFC5015]) would be more efficient. ‘The destination VM sends a standard ARP response using IP unicast. This frame will be encapsulated back to the VTE? connecting the originating VM using IP unicast VKLAN encapsulation. This is possible since the mapping of the ARP response’s destination MAC to the VXLAN tunnel end point IP was learned earlier through the ARP request. Note that multicast frames and “unknown MAC destination" frames are alse sent using the multicast tree, similar to the broadcast frames. 4.3. Physical Infrastructure Requirements When I? multicast is used within the network infrastructure, a multicast routing protocol like PIM-SM can be used by the individual Layer 3 IP routers/switches within the network. This is used to build efficient multicast forwarding trees so that multicast frames are only sent to those hosts (hal have requested to receive then. Similarly, there is no requirement that the actual network connecting the source VM and destination VM should be a Layer 3 network: VXLAN can also work over Layer 2 networks. In either case, efficient multicast replication within the Layer 2 network can be achieved using IGMP snooping. VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may Ezagment encapsulated VXLAN packets due to the larger frame size. ‘The destination VTEP MAY silently discard such VXLAN fragments. To ensure end-to-end traffic delivery without fragmentation, it is RECOMMENDED that the MTUs (Maximum Transmission Units) across the physical network infrastructure be set te a value that accommodates the larger frame size due to the encapsulation. Other techniques like Path MPU discovery (see [RFC1191] and [RFC1981]) MAY be used to address this requirement as well. Mahalingam, et al. Informational, [Page 9]REC 7348 VxLAN August 2014 5. VXLAN Frame Format ‘The VALAN fame format is shown below. Parsing this from the bottom of the frame -- above the outer Frame Check Sequence (FCS), there is an inner MAC frame with its own Ethernet header with source, destination MAC addresses along with the Ethernet type, plus an optional VLAN. See Section 6 for further details of inner VLAN tag handling. ‘The inner MAC frame is encapsulated with the following four headers (starting from the innermost header): VKLAN Header: This is an 8-byte field that hal = Flags (& bite): where the I flag MUST be set to 1 for a valid VXLAN Network 2D (VNI). The other 7 bits (designated "R") are reserved fields and MUST be set to zero on transmission and ignored on receipt. - VXLAN Segment ID/VALAN Network Identifier (NI): this is a 24-bit value used to designate the individual VALAN overlay network on which the communicating VWs are situated. VMs in different VxLAN overlay networks cannot communicate with each other. = Reserved fields (24 bits and 8 bits) transmission and ignored on receipt. MUST be set to zero on outer UDP Header: This is the outer UDP header with a source port provided by the VTRP and the destination port being a well-known UDP port. - Destination Port: IANA has assigned the value 4789 for the VXLAN UDP port, and this value SHOULD be used by default as the destination UD? port. Some early implementations of VXLAN have used other values for the destination port. To enable interoperability with these implementations, the destination port SHOULD be configurable. = Source Port: Tt is recommended that the UDP source port number be calculated using a hash of fields fom the inner packet ~~ one example being a hash of the inner Ethernet frame's headers. This is to enable a level of entropy for the FCMP/Load~ balancing of the V¥-to-VM traffic across the VxLAN overlay. When calculating the UDP source port number in this manner, it is RECOMMENDED that the value be in the dynamic/private port range 49152-65535 [RFC6335]. Mahalingam, et al. Informational, [Page 10]REC 7348 VxLAN August 2014 - UDP Checksum: It SHOULD be transmitted as zero. When a packet Ae received with a UDP checksum cf zero, it MUST be accepted for decapsutation. Optionally, if the encapsulating end point includes a non-zero UDP checksum, it MUST he correctly calculated across the entire packet including the IP header, UDP header, VXLAN header, and encapsulated MAC frame. When’ a decapsulating end point receives a packet with a non-zero checksum, it MAY choose to verify the checksum value. If it ooses to perform such verification, and the verification fails, the packet MUST be droppec. Tf the decapsulating destination chooses not to perform the verification, or performs it successfully, the packet MUST be accepted for decapsulation. outer IP Header: This is the outer IP header with the source IP. address indicating the IP address of the VTE? over which the communicating VM (as represented by the inner source MAC address) is running. The destination IP address can be a unicast or multicast IP address (see Sections 4.1 and 4.2). When it is a unicast IP address, it represents the IP address of the VIEP connecting the communicating VM as represented by the inner destination MAC address. For multicast destination IP addresses, please refer to the scenarios detailed in Section 4.2 outer Ethernet Header (example}: Figure 1 is an example of an inner Ethernet frame encapsulated within an outer Ethernet ~ IP + UDP + VXLAN header. The outer destination MAC address in this frame may be the address of the target VIEP or of an intermediate Layer 3 router. The outer VLAN tag is optional. If present, it may be used for delineating VIAN traffic on the LAN, ° 1 2 3 01234567890123456789012345678901 outer Ethernet Header mtb tebet ttt ttt bat bap teb ett Outer Destination MAC Address Outer Destination MAC Address | Outer Source MAC Address mtb ttt b ttt tet bet tap tet tte outer Source MAC Address JoptniEthtype = C-Tag 802.19 | Outer. VIAN Tag Information | Ethertype = 0x0800 1 Mahalingam, et al. Informational, (Page 11]REC 7348 VxLAN August 2014 outer TPv4 Header: Batt tte ttt ttt ttt tt + lVersion| IHL |Type of Service| Total Length 1 Identification IFlags) Fragment Offset | mtb tpt ttt ttt bt tpt bt tet ote + Time to Live |Proteci=17(UDP)| Header Checksum 1 1 1 Outer Source IPv4 Address ptt ttt bt bap tet tte tote Outer Destination IPvé Address outer UDP Header: Sette Source Port UDP Length eae err VXLAN Header: IRIRIRIRITIRIRIR| Reserved FHP tet pete tet tte 1 VXLAN Network Identifier (VNI) | Reserved Inner Ethernet Header: 1 Inner Destination MAC Address 1 1 Inner Destination MAC Address | Inner Source MAC Address Inner Source MAC Address Joptnigthtype = C-Tag 802.19 | Inner. VLAN Tag Information Payload: Sapte tebe tet ttt + | Ethertype of Original Payload | 1 bbe btebedctotede bedhead ed i i Original Bthernet Payload | i 1 i | (Note that the original Ethernet Frame’s FCS is not included) Mahalingam, et al. Informational, [Page 12]REC 7348 VxLAN August 2014 Frame Check Sequence Bat ett bt ttt ttt tt | New FCS (Frame Check Sequence) for Outer Ethernet Frame 1 Figure 1: VxLAN Frame Format with IPv4 Outer Header ‘The frame format above shows tunneling of Ethernet frames using 1Pv4 for transport. Use of VXLAN with IPv6 transport is detailed below. ° 1 2 3 01234567890123456789012345678901 outer Ethernet. Header: Sette ttt tab p bette ttt + i Outer Destination MAC Address 1 | Outer Destination MAC Address | Outer Source MAC Address 1 Batt bp ttt bt tat ptt tet tet + 1 Outer Source MAC Address 1 JoptniEthtype = C-Tag 802.19 | Outer. VIAN Tag Information | So Ep te tb ted pte teen + | Ethertype = oxsepp 1 outer TPv6 Header: Sati tt |Version| Traffic i Payload Set 1 1 + Outer Source IPv6 Address i 1 SoHE ttt bt top pb ttt tte i 1 + outer Destination IPv6 Address i i Mahalingam, et al. Informational, [Page 13]REC 7348 VxLAN August 2014 outer UDP Header: Batt ttt tt bt ttt be tt Source Port 1 Dest Port = VXLAN Port | UDP Length 1 UDP Checksum 1 mtb ptt tt bt bpp eb be bette de VXLAN Header: IRIRIRIRITIRIRIR| Reserved SHE tet petted 1 VXLAN Network Identifier (VNI) | Reserved Inner Ethernet Header: 1 Inner Destination MAC Address i 1 Inner Destination MAC Address | Inner Source MAC Address inner Source MAC Address c-Tag 802.19 | Inner.VIAN Tag Information ott t bt batt et ot tte ate tte Joptnigthtype = Sot Payloas | Ethertype of Original Payload | 1 i | (Note that the original Ethernet Frame’s FCS is not included) 1 i original Bthernet Payload | i i Frame Check Sequence Fat ptt ttt bt tabbed tet ttt | New PCS (Frame Check Sequence) for Outer Ethernet Frame 1 Figure 2: VxIAN Frame Format with TPv6 Outer Header 6. VXLAN Deployment Scenarios VKLAN is typically deployed in data centers on virtualized hosts, which may be spread across multiple racks. The individual racks’ may be parts of a different Layer 3 network or they could be in a single Layer 2 network. The VKLAN segments/overlay networks are overlaid on top of these Layer 2 or Layer 3 networks. Mahalingam, et al. Informational, [Page 14]REC 7348 VxLAN August 2014 Consider Figure 3, which depicts two virtualized servers attached to a Layer 3 infrastructure. ‘The servers could be on the same rack, on different racks, or potentially across data centers within the same adtinistrative domain. There are four VXLAN overlay networks identified by the VNIs 22, 34, 14, and 98. Consider the case of VMI-1 in Server 1 and VM2~4 on Server 2, which are on the same VXLAN overlay network identified by VNI 22. The VMs de not know about the overlay networks and transport method since the encapsulation and decapsulation happen transparently at the VTEPs on Servers 1 and 2. ‘The other overlay networks and the corresponding VMs are VMI-2 on Server 1 and YM2-1 on Server 2, both on VNI 34; VML-3 on Server 1 and vM2-2 on Server 2 on VNI 74; and finally VM1-4 on Server 1 and VM2-3 on Server 2 on VNI 98. Mahalingam, et al. Informational, [Page 19]REC 7348 1 Server 1 i tenant pemec tenant jovwi-2 | jvwi-2 | |vNr 2200 | IweT 34 | it iol I i + i i + Jolvwi-3 | jvwina | | lvyr 740 | |vwr 98 | it Il 1 je + + | Aypervisor VTEP VxLAN Layer 3 Network August 2014 jym2-2 |VNI 34 Figure 3: VXLAN Deployment - VIEPs across a Layer 3 Network Mahalingam, et al. Informational, [Page 16]REC 7348 VxLAN August 2014 one deployment scenario is where the tunnel termination point is a physical server that. understands VXLAN., An alternate scenario 1s where nodes on a VXLAN overlay network need to communicate with nodes on legacy networks that could be VLAN based. These nodes may be physical nodes or virtual machines, To enable this communication, a network can include VXLAN gateways (see Figure 4 below with a switch acting as a VXLAN gateway) that forward traffic between VXLAN and non-VXLAN environments. Consider Figure 4 for the following discussion. For incoming frames on the VXLAN connected interface, the gateway strips out the VXLAN header and forwards it to a physical port based on the destination MAC address of the inner Ethernet frame. Decapsulated frames with the inner VLAN ID SHOULD be discarded unless configured explicitly to be passed on to the non-VXLAN interface. In the reverse direction, incoming frames for the non-VXLAN interfaces aze mapped to a specific VALAN overlay network based on the VLAN ID in the frame. Unless configured explicitly to be passed on in the encapsulated VXLAN frame, this VLAN 2D is removed before the frame is encapsulated for VxLAN. ‘These gateways that provide VXLAN tunnel termination functions could be ToR/access switches or switches higher up in the data center network topology -- e.g., core or even WAN edge devices. The last case (WAN edge) could involve a Provider Edge (25) router that terminates VXLAN tunnels in a hybrid cloud environment. In all these instances, note that the gateway functionality could be implemented in software or hardware. Mahalingam, et al. Informational, [Page 17]REC 7348 VxLAN August 2014 | Server 1 | | Non-VxXLAN | (VXLAN enabled) <~ server i _ Non-VXLAN | server | + |Server 2 1 (VXLAN enabled) <~ [Switch acting) I | as VxIAN |- | Gateway | + | Server 3 | (VELAN enabled) <~ | Server 4 | (WXLAN enabled) <~ + + Figure 4: VXLAN Deployment - VXLAN Gateway 6.1. Inner VIAN Tag Handling Inner VLAN Tag Handling in VTEP and VXLAN gateway should conform to the following: Decapsulated VXLAN franes with the inner VLAN Lag SHOULD be discarded unless configured otherwise. On the encapsulation side, a VZEP SHOULD NOT include an inner VLAN tag on tunnel packets unless configured otherwise. When a VLAN-tagged packet is a candidate for VKLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag unless configured otherwise. J. Security Considerations ‘Traditionally, Layer 2 networks can only be attacked from ‘within’ by rogue end points -- either by having inappropriate access to a LAN and snooping on traffic, by injecting spoofed packets to ‘take over’ another MAC address, or by flooding and causing denial of service. A MaC-over-IP mechanism for delivering Layer 2 traffic significantly extends this attack surface. This can happen by rogues injecting themselves into the network by subscribing to one or more multicast, groups that carry broadcast traffic for VXLAN segments and also by sourcing MAC-over-UDP frames inte the transport network to inject spurious traffic, possibly to hijack MAC addresses. Mahalingam, et al. Informational, Page 18)REC 7348 VxLAN August 2014 This document does not incorporate specific measures against such attacks, relying instead on other traditional mechanisms layered on top of 12, Thies section, instead, sketches out some possible approaches to security in the VXLAN environment. ‘Traditional Layer 2 attacks by rogue end points can be mitigated by limiting the management and administrative scope of who deploys and manages VMs/gateways in a VXLAN environment. In addition, such adninistrative measures may be augmented by schemes like 802.1X [802.1] for admission control of individual end points. Also, the use of the UDP-based encapsulation of VXLAN enables configuration and use of the 5-tuple-based ACL (Access Control List) functionality in physical switches. Tunneled traffic over the IP network can be secured with traditional security mechanisms like IPsec that authenticate and optionally encrypt VXLAN traffic. This will, of course, need to be coupled with an authentication infrastructure for authorized end points to obtain and distribute credentials. VALAN overlay networks are designated and operated over the existing IAN infrastructure. To ensure that VKLAN end points and their VTEPs are authorized on the LAN, it is recommended that a VLAN be designated for VXLAN traffic and the servers/VTEPs send VXLAN traffic over this VLAN to provide a measure of security. In addition, VXIAN requires proper mapping of VNIs and VM membership in these overlay networks. It is expected thal this mapping be done and communicated to the management entity on the VPEP and the gateways using existing secure methods. 8. IANA Considerations A well-known UDP port (4789) has been assigned by the IANA in the Service Name and Transport Protocol Port Number Registry for VKLAN. See Section 5 for discussion of the port number. 9. References 9.1, Normative References [RPC2119] Bradner, $., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Mahalingam, et al. Informational, [Page 19]REC 7348 VxLAN August 2014 9.2. Informative References [802.laq] IEEE, "Standard for Local and metropolitan area networks —- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE P802.1aq-2012, 2012. [802.1D] IEEE, “Draft Standard for Local and Metropolitan Area Networks/ Media Access Control (MAC) Bridges", TEEB P802.1D=2004, 2004. [802.1X] IEEE, “ZPSE Standard for Local and metropolitan area networks =~ Port-Based Network Acces Control", IEEE Std 802.1X-2020, February 2010. [REC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 2990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, “Considerations for Internet Group Management. Protocol (1GMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and T. Kouvelas, “Protocol Independent Multicast - Sparse Mode (P=M-SM) : Protoco? Specification (Revised)", RFC 4601, August 2006. [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirect!onal Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. IRFC6325] Perlman, R., Bastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwan‘, “Routing Bridges (RBridges): Base Protocol Specification", REC 6325, July 2011. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and 3. Cheshire, “Internet Assigned Numbers Authority (7ANA) Procedures for the Management of the Service Name and ‘Transport Protocol Port Number Registry", BCP 165, RFC 6335, August 2011. Mahalingam, et al. Informational, [Page 20]REC 7348 VxLAN 10. Acknowledgments August 2014 ‘The authors wish to thank: Ajit Sanzgiri for contributions to the Security Considerations section and editorial inputs; Margaret Petrus, Milin Desai, Nial de Barra, Kollipara for their editorial reviews, inputs, Authors’ Addresses Mallik Mehalingam Storviser, Inc. 640 W. California Ave, Suite #110 Sunnyvale, CA 94086. USA EMail: mallik_mahalingam@yahoo.com Dinesh G. Dutt Cumulus Networks 140¢ 8. Whisman Road Mountain View, CA 94041 USA EMail: ddutt.ietf@hobbesdutt.com Kenneth Duda Arista Networks 5453 Great America Parkway Santa Clara, CA 95054 usa EMail: kduda@arista.con Puneet Agarwal Broadcom Corporation 3151 Zanker Road San Jose, CA 99134 usa EMail: pagarwal@broadcom.com Mahalingam, et al. Informational, Joseph Cheng, Jeff Mandin, ‘and comments. and Siva (Page 21]REC 7348 VxLAN August 2014 Lawrence Kreeger Cisco Systems, Inc. 170 W. Tasman Avenue San Jose, CA 95134 USA, EMail: kreeger@cisco.com 7. Sridhar Vuware, Inc. 3401 Hillview Palo Alto, CA 94304 USA, EMail: tsridhar@vmware.com Mike Bursell Intel Bowyer’s, North Road Great Yeldham Halstead Essex. cO9 49D uk EMail: mike.bursell@intel.com Chris wright Red Hat, Inc. 100 East Davie Street Raleigh, NC 27601 usa. EMail: chrisw@redhat.com Mahalingam, et al. Informational, [Page 22]