idnits 2.17.1 draft-quinn-vxlan-gpe-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A VXLAN-gpe VTEP MUST not encapsulate non-Ethernet frames to a VXLAN VTEP. When encapsulating Ethernet frames to a VXLAN VTEP the P bit will be set to 1 and the Protocol Type set to 0x6558. The VXLAN VTEP will ignore the P bit and the Protocol Type, and treat the packet as a VXLAN packet (i.e. the payload is Ethernet) -- The document date (October 1, 2013) is 3861 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Quinn 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational P. Agarwal 5 Expires: April 4, 2014 Broadcom 6 R. Fernando 7 L. Kreeger 8 D. Lewis 9 F. Maino 10 Cisco Systems, Inc. 11 M. Smith 12 N. Yadav 13 Insieme Networks 14 October 1, 2013 16 Generic Protocol Extension for VXLAN 17 draft-quinn-vxlan-gpe-01.txt 19 Abstract 21 This draft describes a mechanism for adding multi-protocol support to 22 Virtual eXtensible Local Area Network (VXLAN). Protocol 23 identification is carried in the VXLAN header and is used to describe 24 the encapsulated payload. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 4, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. VXLAN Without Protocol Extension . . . . . . . . . . . . . . . 4 62 3. Generic Protocol Extension VXLAN (VXLAN-gpe) . . . . . . . . . 5 63 3.1. VXLAN Header . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 65 4.1. VXLAN VTEP to VXLAN-gpe VTEP . . . . . . . . . . . . . . . 6 66 4.2. VXLAN-gpe VTEP to VXLAN VTEP . . . . . . . . . . . . . . . 6 67 4.3. IP Type of Service/Traffic Class . . . . . . . . . . . . . 6 68 5. VXLAN-gpe Examples . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Virtual eXtensible Local Area Network [VXLAN] defines an 80 encapsulation format that encapsulates Ethernet frames in an outer 81 UDP/IP transport. The VXLAN header does not specify the protocol 82 being encapsulated and therefore is currently limited to 83 encapsulating only Ethernet frame payloads. As data centers evolve, 84 the need to carry other protocols in an encapsulated IP packet is 85 required. Rather than defining yet another encapsulation, VXLAN can 86 be extended to indicate the inner protocol, thus broadening the 87 applicability of VXLAN. 89 This document describes extending VXLAN to support additional payload 90 types beyond Ethernet frames. To support this capability, two 91 elements of the existing VXLAN header are modified. 93 1. A reserved bit is allocated, and set in the VXLAN header. 95 2. A 16 bit Protocol Type field is present in the VXLAN header. 97 These two changes allow for the VXLAN header to support many 98 different types of payloads, all the while maintaining backward 99 compatibility with existing VXLAN deployments. 101 2. VXLAN Without Protocol Extension 103 As described in the introduction, the VXLAN header has no protocol 104 identifier that indicates the type of payload being carried by VXLAN. 105 Because of this, VXLAN is limited to an Ethernet payload. 107 The VXLAN header defines flags (some defined, some reserved), the 108 VXLAN network identifier (VNI) field and several reserved bits. The 109 flags provide flexibility to define how the reserved bits can be used 110 to change the definition of the VXLAN header. 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 |R|R|R|R|I|R|R|R| Reserved | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | VXLAN Network Identifier (VNI) | Reserved | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 1: VXLAN Header 122 3. Generic Protocol Extension VXLAN (VXLAN-gpe) 124 3.1. VXLAN Header 126 This draft defines two changes to the VXLAN header in order to 127 support multi-protocol encapsulation. 129 P Bit: Flag bit 5 is defined as the P bit. The P bit MUST be set to 130 1 to indicate the presence of the 16 bit protocol type field in 131 the lower 16 bits of the first word. 133 P = 0 indicates that the payload MUST conform to VXLAN as defined 134 in [VXLAN]. 136 Flag bit 5 was chosen as the P bit because this flag bit is 137 currently reserved in VXLAN. 139 Protocol Type Field: The lower 16 bits of the first word are used to 140 carry a protocol type. This protocol type field contains the 141 protocol, as defined in in [RFC1700] and in [ETYPES], of the 142 encapsulated payload packet. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Source Port = xxxx | Dest Port = 4789 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | UDP Length | UDP Checksum | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |R|R|R|R|I|P|R|R| Reserved | Protocol Type | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | VXLAN Network Identifier (VNI) | Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Figure 2: UDP + VXLAN-gpe 158 4. Backward Compatibility 160 In order to ensure compatibility with existing VXLAN deployments, P = 161 0 indicates that the encapsulated payload MUST be Ethernet. 163 4.1. VXLAN VTEP to VXLAN-gpe VTEP 165 If a packet is sent from a VXLAN VTEP to a VXLAN-gpe VTEP, the P bit 166 MUST be set to 0, and the remaining fields remain as described in 167 [VXLAN]. The encapsulated payload MUST be Ethernet. 169 4.2. VXLAN-gpe VTEP to VXLAN VTEP 171 A VXLAN-gpe VTEP MUST not encapsulate non-Ethernet frames to a VXLAN 172 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP the P bit 173 will be set to 1 and the Protocol Type set to 0x6558. The VXLAN VTEP 174 will ignore the P bit and the Protocol Type, and treat the packet as 175 a VXLAN packet (i.e. the payload is Ethernet) 177 A method for determining the capabilities of a VXLAN VTEP (gpe or 178 non-gpe) is out of the scope of this draft. 180 4.3. IP Type of Service/Traffic Class 182 When a VXLAN-gpe VTEP performs IPv4 encapsulation, the inner IPv4 183 Type of Service field MAY be copied from the encapsulated packet to 184 the Type of Service or Traffic Class field in the outer IPv4 or IPv6 185 header respectively. 187 Similarly, when a VXLAN-gpe VTEP performs IPv6 encapsulation, the 188 inner IPv6 Traffic Class field MAY be copied from the encapsulated 189 packet to the Type of Service or Traffic Class field in the outer 190 IPv4 or IPv6 header respectively. 192 5. VXLAN-gpe Examples 194 This section provides three examples of protocols encapsulated using 195 the Generic Protocol Extension for VXLAN described in this document. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |R|R|R|R|I|1|R|R| Reserved | 0x0800 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | VXLAN Network Identifier (VNI) | Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Original IPv4 Packet | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 3: IPv4 and VXLAN-gpe 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |R|R|R|R|I|1|R|R| Reserved | 0x86DD | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | VXLAN Network Identifier (VNI) | Reserved | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Original IPv6 Packet | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 4: IPv6 and VXLAN-gpe 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |R|R|R|R|I|1|R|R| Reserved | 0x6558 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | VXLAN Network Identifier (VNI) | Reserved | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Original Ethernet Frame | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 5: Ethernet and VXLAN-gpe 233 6. Security Considerations 235 VXLAN's security is focused on issues around L2 encapsulation into 236 L3. With VXLAN-gpe, issues such as spoofing, flooding, and traffic 237 redirection are dependent on the particular protocol payload 238 encapsulated. 240 7. Acknowledgments 242 A special thank you goes to Dino Farinacci for his guidance and 243 detailed review. 245 8. IANA Considerations 247 This document creates no new requirements on IANA namespaces 248 [RFC5226]. 250 9. References 252 9.1. Normative References 254 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 255 August 1980. 257 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 258 September 1981. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 264 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 265 May 2008. 267 9.2. Informative References 269 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 270 . 273 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 274 October 1994. 276 [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger, 277 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 278 Framework for Overlaying Virtualized Layer 2 Networks over 279 Layer 3 Networks", 2013. 281 Authors' Addresses 283 Paul Quinn 284 Cisco Systems, Inc. 286 Email: paulq@cisco.com 288 Puneet Agarwal 289 Broadcom 291 Email: pagarwal@broadcom.com 293 Rex Fernando 294 Cisco Systems, Inc. 296 Email: rex@cisco.com 298 Larry Kreeger 299 Cisco Systems, Inc. 301 Email: kreeger@cisco.com 303 Darrel Lewis 304 Cisco Systems, Inc. 306 Email: darlewis@cisco.com 308 Fabio Maino 309 Cisco Systems, Inc. 311 Email: kreeger@cisco.com 313 Michael Smith 314 Insieme Networks 316 Email: michsmit@insiemenetworks.com 317 Navindra Yadav 318 Insieme Networks 320 Email: nyadav@insiemenetworks.com