idnits 2.17.1 draft-lewis-lisp-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6830]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 LISP-gpe router MUST not encapsulate non-IP packets to a LISP router. A method for determining the capabilities of a LISP router (gpe or "legacy") is out of the scope of this draft. == 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: When a LISP-gpe router receives a packet from a (legacy) LISP router, the P bit MUST not be set and the UDP port MUST be 4341. The payload MUST be IP, and the LISP-gpe router will inspect the first nibble of the payload to determine IP version. -- The document date (October 1, 2013) is 3859 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 282, 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) -- Obsolete informational reference (is this intentional?): RFC 6834 (Obsoleted by RFC 9302) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Lewis 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational P. Agarwal 5 Expires: April 4, 2014 Broadcom 6 L. Kreeger 7 F. Maino 8 P. Quinn 9 Cisco Systems, Inc. 10 M. Smith 11 N. Yadav 12 Insieme Networks 13 October 1, 2013 15 LISP Generic Protocol Extension 16 draft-lewis-lisp-gpe-01.txt 18 Abstract 20 This draft describes a mechanism for adding generalized multi- 21 protocol support to the Locator/ID Separation Protocol (LISP) 22 [RFC6830]. Protocol identification is carried in the LISP header and 23 is used to describe the encapsulated payload. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 4, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. LISP Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Generic Protocol Extension for LISP (LISP-gpe) . . . . . . . . 5 62 3.1. LISP-gpe Header . . . . . . . . . . . . . . . . . . . . . 5 63 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 64 4.1. LISP-gpe Routers to (legacy) LISP Routers . . . . . . . . 6 65 4.2. (legacy) LISP Routers to LISP-gpe Routers . . . . . . . . 6 66 4.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 6 67 4.4. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6 68 5. LISP-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 LISP [RFC6830] defines an encapsulation format that carries IPv4 or 80 IPv6 (henceforth referred to as IP) packets in a LISP header and 81 outer UDP/IP transport. The LISP header does not specify the 82 protocol being encapsulated and therefore is currently limited to 83 encapsulating only IP packet payloads. Other protocols, most notably 84 VXLAN [VXLAN] (which defines a similar header format to LISP), are 85 used to encapsulate L2 protocols such as Ethernet. LISP [RFC6830] 86 can be extended to indicate the inner protocol, enabling the 87 encapsulation of Ethernet, IP or any other desired protocol all the 88 while ensuring compatibility with existing LISP [RFC6830] 89 deployments. 91 This document describes extending LISP ([RFC6830]) to support 92 additional payload types beyond IP packets. To support this 93 capability, two elements of the existing LISP header are modified. 95 1. A flag bit is allocated, and set in the LISP header. 97 2. A 16 bit Protocol Type field is present in the LISP header. 99 These changes allow for the LISP header to support many different 100 types of payloads. Backward compatibility with existing LISP tunnel 101 routers is discussed in section 4. 103 2. LISP Header 105 As described in the introduction, the LISP header has no protocol 106 identifier that indicates the type of payload being carried by LISP. 107 Because of this, LISP is limited to an IP payload. 109 The LISP header contains flags (some defined, some reserved), a 110 Nonce/Map-version field and an instance ID/Locator-status-bit field. 111 The flags provide flexibility to define how the reserved bits can be 112 used to change the definition of the LISP header. 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 |N|L|E|V|I|flags| Nonce/Map-Version | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Instance ID/Locator-Status-Bits | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Figure 1: LISP Header 122 3. Generic Protocol Extension for LISP (LISP-gpe) 124 3.1. LISP-gpe Header 126 This draft defines two changes to the LISP header in order to support 127 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 LISP as defined 134 in [RFC6830]. 136 Flag bit 5 was chosen as the P bit because this flag bit is 137 currently unallocated in LISP [RFC6830]. 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 LISP [RFC6830] uses the lower 16 bits of the first word for either 145 a nonce, an echo-nonce ([RFC6830]) or to support map-versioning 146 ([RFC6834]). These are all optional capabilities that are 147 indicated by setting the N, E, and the V bit respectively. 149 To maintain the desired data plane compatibility, when the P bit 150 is set, the N, E, and V bits MUST be set to zero. 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Source Port = xxxx | Dest Port = 4341 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | UDP Length | UDP Checksum | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 |N|L|E|V|I|P|R|R| Reserved |Nonce/Map-Version/Protocol-Type| 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Instance ID/Locator-Status-Bits | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 2: UDP + LISP-gpe 166 4. Backward Compatibility 168 An undefined (in RFC6830) flag bit, 5, was selected to ensure 169 compatibility with existing LISP [RFC6830] deployments. 171 Similarly, using P = 0 to indicate that the format of the header and 172 payload conforms to [RFC6830] ensures compatibility with existing 173 LISP hardware forwarding platforms. 175 4.1. LISP-gpe Routers to (legacy) LISP Routers 177 A LISP-gpe router MUST not encapsulate non-IP packets to a LISP 178 router. A method for determining the capabilities of a LISP router 179 (gpe or "legacy") is out of the scope of this draft. 181 When encapsulating IP packets to a LISP router the P bit SHOULD be 182 set to 1 and the UDP port MUST be set to 4341. The Protocol Type 183 field SHOULD be 0x800 or 0x86DD. The (legacy) LISP router will 184 ignore the P bit and the protocol type field. The (legacy) LISP 185 router will treat the packet as a LISP packet and inspect the first 186 nibble of the payload to determine the IP version. 188 When the P bit is set, the N, E, and V bits MUST be set to zero. The 189 receiving (legacy) LISP router will ignore N, E and V bits, when the 190 P bit is set. 192 4.2. (legacy) LISP Routers to LISP-gpe Routers 194 When a LISP-gpe router receives a packet from a (legacy) LISP router, 195 the P bit MUST not be set and the UDP port MUST be 4341. The payload 196 MUST be IP, and the LISP-gpe router will inspect the first nibble of 197 the payload to determine IP version. 199 4.3. Type of Service 201 When a LISP-gpe router performs Ethernet encapsulation, the inner 202 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from 203 the encapsulated frame to the Type of Service field in the outer IPv4 204 header, or in the case of IPv6 the 'Traffic Class' field. 206 4.4. VLAN Identifier (VID) 208 When a LISP-gpe router performs Ethernet encapsulation, the inner 209 header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 210 used to determine the LISP Instance ID field. 212 5. LISP-gpe Examples 214 This section provides two examples of IP protocols, and one example 215 of Ethernet encapsulated LISP-gpe using the generic extension 216 described in this document. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 |N|L|E|V|I|1|R|R| Reserved | 0x800 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Instance ID/Locator-Status-Bits | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Original IPv4 Packet | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 3: IPv4 and LISP-gpe 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |N|L|E|V|I|1|R|R| Reserved | 0x86DD | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Instance ID/Locator-Status-Bits | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Original IPv6 Packet | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 4: IPv6 and LISP-gpe 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 |N|L|E|V|I|1|R|R| Reserved | 0x6558 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Instance ID/Locator-Status-Bits | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Original Ethernet Frame | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 5: Ethernet and LISP-gpe 254 6. Security Considerations 256 LISP-gpe security considerations are similar to the LISP security 257 considerations documented at length in LISP [RFC6830]. With LISP- 258 gpe, issues such as dataplane spoofing, flooding, and traffic 259 redirection are dependent on the particular protocol payload 260 encapsulated. 262 7. Acknowledgments 264 A special thank you goes to Dino Farinacci for his guidance and 265 detailed review. 267 8. IANA Considerations 269 This document creates no new requirements on IANA namespaces 270 [RFC5226]. 272 9. References 274 9.1. Normative References 276 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 277 August 1980. 279 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 280 September 1981. 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, March 1997. 285 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 286 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 287 May 2008. 289 9.2. Informative References 291 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 292 . 295 [IEEE8021Q] 296 The IEEE Computer Society, "Media Access Control (MAC) 297 Bridges and Virtual Bridge Local Area Networks", August 298 2012, . 301 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 302 October 1994. 304 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 305 Locator/ID Separation Protocol (LISP)", RFC 6830, 306 January 2013. 308 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 309 Separation Protocol (LISP) Map-Versioning", RFC 6834, 310 January 2013. 312 [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger, 313 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 314 Framework for Overlaying Virtualized Layer 2 Networks over 315 Layer 3 Networks", 2013. 317 Authors' Addresses 319 Darrel Lewis 320 Cisco Systems, Inc. 322 Email: darlewis@cisco.com 324 Puneet Agarwal 325 Broadcom 327 Email: pagarwal@broadcom.com 329 Larry Kreeger 330 Cisco Systems, Inc. 332 Email: kreeger@cisco.com 334 Fabio Maino 335 Cisco Systems, Inc. 337 Email: kreeger@cisco.com 339 Paul Quinn 340 Cisco Systems, Inc. 342 Email: paulq@cisco.com 344 Michael Smith 345 Insieme Networks 347 Email: michsmit@insiemenetworks.com 349 Navindra Yadav 350 Insieme Networks 352 Email: nyadav@insiemenetworks.com