idnits 2.17.1 draft-quinn-vxlan-gpe-02.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 VXLAN-gpe VTEP will set the P bit to 1 and the Protocol Type 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 (December 16, 2013) is 3783 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 264, 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) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Agarwal 3 Internet-Draft Broadcom 4 Intended status: Experimental R. Fernando 5 Expires: June 19, 2014 L. Kreeger 6 D. Lewis 7 F. Maino 8 P. Quinn 9 Cisco Systems, Inc. 10 L. Yong 11 Huawei USA 12 X. Xu 13 Huawei Technologies 14 M. Smith 15 N. Yadav 16 Insieme Networks 17 U. Elzur 18 Intel 19 December 16, 2013 21 Generic Protocol Extension for VXLAN 22 draft-quinn-vxlan-gpe-02.txt 24 Abstract 26 This draft describes a mechanism for adding multi-protocol support to 27 Virtual eXtensible Local Area Network (VXLAN). Protocol 28 identification is carried in the VXLAN header and is used to describe 29 the encapsulated payload. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 19, 2014. 48 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 respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. VXLAN Without Protocol Extension . . . . . . . . . . . . . . . 4 66 3. Generic Protocol Extension VXLAN (VXLAN-gpe) . . . . . . . . . 5 67 3.1. VXLAN Header . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 69 4.1. VXLAN VTEP to VXLAN-gpe VTEP . . . . . . . . . . . . . . . 6 70 4.2. VXLAN-gpe VTEP to VXLAN VTEP . . . . . . . . . . . . . . . 6 71 5. VXLAN-gpe and Encapsulated IP Header Fields . . . . . . . . . 7 72 6. VXLAN-gpe Examples . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Virtual eXtensible Local Area Network [VXLAN] defines an 84 encapsulation format that encapsulates Ethernet frames in an outer 85 UDP/IP transport. The VXLAN header does not specify the protocol 86 being encapsulated and therefore is currently limited to 87 encapsulating only Ethernet frame payloads. As data centers evolve, 88 the need to carry other protocols encapsulated in an IP packet is 89 required. Rather than defining yet another encapsulation, VXLAN can 90 be extended to indicate the inner protocol, thus broadening the 91 applicability of VXLAN. 93 This document describes extending VXLAN to support additional payload 94 types beyond Ethernet frames. To support this capability, two 95 elements of the existing VXLAN header are modified. For IPv4/v6 96 payloads, this document also specifies expected behavior for handling 97 certain inner IP header fields. 99 1. A reserved bit is allocated, and set in the VXLAN header. 101 2. A 16 bit Protocol Type field is present in the VXLAN header. 103 These two changes allow for the VXLAN header to support many 104 different types of payloads, all the while maintaining backward 105 compatibility with existing VXLAN deployments. 107 2. VXLAN Without Protocol Extension 109 As described in the introduction, the VXLAN header has no protocol 110 identifier that indicates the type of payload being carried by VXLAN. 111 Because of this, VXLAN is limited to an Ethernet payload. 113 The VXLAN header defines bits 0-7 as flags (some defined, some 114 reserved), the VXLAN network identifier (VNI) field and several 115 reserved bits. The flags provide flexibility to define how the 116 reserved bits can be used to change the definition of the VXLAN 117 header. 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 |R|R|R|R|I|R|R|R| Reserved | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | VXLAN Network Identifier (VNI) | Reserved | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Figure 1: VXLAN Header 129 3. Generic Protocol Extension VXLAN (VXLAN-gpe) 131 3.1. VXLAN Header 133 This draft defines two changes to the VXLAN header in order to 134 support multi-protocol encapsulation. 136 P Bit: Flag bit 5 is defined as the P bit. The P bit MUST be set to 137 1 to indicate the presence of the 16 bit protocol type field in 138 the lower 16 bits of the first word. 140 P = 0 indicates that the payload MUST conform to VXLAN as defined 141 in [VXLAN]. 143 Flag bit 5 was chosen as the P bit because this flag bit is 144 currently reserved in VXLAN. 146 Protocol Type Field: The lower 16 bits of the first word are used to 147 carry a protocol type. This protocol type field contains the 148 protocol, as defined in in [RFC1700] and in [ETYPES], of the 149 encapsulated payload packet. 151 VXLAN-gpe does not impact the UDP header; more specifically the 152 destination port is 4789 as defined in [VXLAN]. 154 0 1 2 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 |R|R|R|R|I|P|R|R| Reserved | Protocol Type | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | VXLAN Network Identifier (VNI) | Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 2: VXLAN-gpe 164 4. Backward Compatibility 166 In order to ensure compatibility with existing VXLAN deployments, P = 167 0 indicates that the encapsulated payload MUST be Ethernet. 169 4.1. VXLAN VTEP to VXLAN-gpe VTEP 171 If a packet is sent from a VXLAN VTEP to a VXLAN-gpe VTEP, the P is 172 set to 0, and the remaining fields remain as described in [VXLAN]. 173 The encapsulated payload MUST be Ethernet. 175 4.2. VXLAN-gpe VTEP to VXLAN VTEP 177 A VXLAN-gpe VTEP MUST not encapsulate non-Ethernet frames to a VXLAN 178 VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the VXLAN- 179 gpe VTEP will set the P bit to 1 and the Protocol Type to 0x6558. 180 The VXLAN VTEP will ignore the P bit and the Protocol Type, and treat 181 the packet as a VXLAN packet (i.e. the payload is Ethernet) 183 A method for determining the capabilities of a VXLAN VTEP (gpe or 184 non-gpe) is out of the scope of this draft. 186 5. VXLAN-gpe and Encapsulated IP Header Fields 188 When encapsulating and decapsulating IPv4 and IPv6 packets certains 189 fields such as IPv4 Time to Live (TTL) from the inner IP header need 190 to be considered. VXLAN-gpe IP encapsulation and decapsulation 191 utilizes the techniques described in [RFC6830], section 5.3. 193 6. VXLAN-gpe Examples 195 This section provides three examples of protocols encapsulated using 196 the Generic Protocol Extension for VXLAN described in this document. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |R|R|R|R|I|1|R|R| Reserved | 0x0800 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | VXLAN Network Identifier (VNI) | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Original IPv4 Packet | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 3: IPv4 and VXLAN-gpe 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |R|R|R|R|I|1|R|R| Reserved | 0x86DD | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | VXLAN Network Identifier (VNI) | Reserved | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Original IPv6 Packet | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 4: IPv6 and VXLAN-gpe 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |R|R|R|R|I|1|R|R| Reserved | 0x6558 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | VXLAN Network Identifier (VNI) | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Original Ethernet Frame | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 5: Ethernet and VXLAN-gpe 234 7. Security Considerations 236 VXLAN's security is focused on issues around L2 encapsulation into 237 L3. With VXLAN-gpe, issues such as spoofing, flooding, and traffic 238 redirection are dependent on the particular protocol payload 239 encapsulated. 241 8. Acknowledgments 243 A special thank you goes to Dino Farinacci for his guidance and 244 detailed review. 246 Note that the contributors to this document are listed in 247 alphabetical order according to their organizational affiliation. 249 9. IANA Considerations 251 This document creates no new requirements on IANA namespaces 252 [RFC5226]. 254 10. References 256 10.1. Normative References 258 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 259 August 1980. 261 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 262 September 1981. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 268 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 269 May 2008. 271 10.2. Informative References 273 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 274 . 277 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 278 October 1994. 280 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 281 Locator/ID Separation Protocol (LISP)", RFC 6830, 282 January 2013. 284 [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger, 285 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 286 Framework for Overlaying Virtualized Layer 2 Networks over 287 Layer 3 Networks", 2013. 289 Authors' Addresses 291 Puneet Agarwal 292 Broadcom 294 Email: pagarwal@broadcom.com 296 Rex Fernando 297 Cisco Systems, Inc. 299 Email: rex@cisco.com 301 Larry Kreeger 302 Cisco Systems, Inc. 304 Email: kreeger@cisco.com 306 Darrel Lewis 307 Cisco Systems, Inc. 309 Email: darlewis@cisco.com 311 Fabio Maino 312 Cisco Systems, Inc. 314 Email: kreeger@cisco.com 316 Paul Quinn 317 Cisco Systems, Inc. 319 Email: paulq@cisco.com 321 Lucy Yong 322 Huawei USA 324 Email: lucy.yong@huawei.com 325 Xiaohu Xu 326 Huawei Technologies 328 Email: xuxiaohu@huawei.com 330 Michael Smith 331 Insieme Networks 333 Email: michsmit@insiemenetworks.com 335 Navindra Yadav 336 Insieme Networks 338 Email: nyadav@insiemenetworks.com 340 Uri Elzur 341 Intel 343 Email: uri.elzur@intel.com