idnits 2.17.1 draft-lewis-lisp-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 : ---------------------------------------------------------------------------- ** 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 packet nor OAM 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 (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 366, but no explicit reference was found in the text == Unused Reference: 'ETYPES' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC1700' is defined on line 385, 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 (~~), 9 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: January 5, 2015 Broadcom 6 L. Kreeger 7 F. Maino 8 P. Quinn 9 M. Smith 10 N. Yadav 11 Cisco Systems, Inc. 12 July 4, 2014 14 LISP Generic Protocol Extension 15 draft-lewis-lisp-gpe-02.txt 17 Abstract 19 This draft describes extending the Locator/ID Separation Protocol 20 (LISP) [RFC6830], via changes to the LISP header, with three new 21 capabilities: support for multi-protocol encapsulation, operations, 22 administration and management (OAM) signaling, and explicit 23 versioning. 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 January 5, 2015. 42 Copyright Notice 44 Copyright (c) 2014 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 Without Protocol Extensions . . . . . . . . . . . 4 61 3. Generic Protocol Extension for LISP (LISP-gpe) . . . . . . . . 5 62 3.1. Multi Protocol Support . . . . . . . . . . . . . . . . . . 5 63 3.2. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Version Bits . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 66 4.1. LISP-gpe Routers to (legacy) LISP Routers . . . . . . . . 8 67 4.2. (legacy) LISP Routers to LISP-gpe Routers . . . . . . . . 8 68 4.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 8 69 4.4. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 8 70 5. LISP-gpe Examples . . . . . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 LISP [RFC6830] defines an encapsulation format that carries IPv4 or 82 IPv6 (henceforth referred to as IP) packets in a LISP header and 83 outer UDP/IP transport. 85 The LISP header does not specify the protocol being encapsulated and 86 therefore is currently limited to encapsulating only IP packet 87 payloads. Other protocols, most notably VXLAN [VXLAN] (which defines 88 a similar header format to LISP), are used to encapsulate L2 89 protocols such as Ethernet. LISP [RFC6830] can be extended to 90 indicate the inner protocol, enabling the encapsulation of Ethernet, 91 IP or any other desired protocol all the while ensuring compatibility 92 with existing LISP [RFC6830] deployments. 94 As LISP is deployed, there's also the need to provide increased 95 visibility and diagnostic capabilities within the overlay. 97 This document describes extending LISP ([RFC6830]) via the following 98 changes: 100 Next Protocol Bit (P bit): A reserved flag bit is allocated, and set 101 in the LISP-gpe header to indicate that a next protocol field is 102 present. 104 OAM Flag Bit (O bit): A reserved flag bit is allocated, and set in 105 the LISP-gpe header, to indicate that the packet is an OAM packet. 107 Version: Two reserved bits are allocated, and set in the LISP-gpe 108 header, to indicate LISP-gpe protocol version. 110 Next protocol: An 8 bit next protocol field is present in the LISP- 111 gpe header. 113 2. LISP Header Without Protocol Extensions 115 As described in the introduction, the LISP header has no protocol 116 identifier that indicates the type of payload being carried by LISP. 117 Because of this, LISP is limited to an IP payload. Furthermore, the 118 LISP header has no mechanism to signal OAM packets. 120 The LISP header contains flags (some defined, some reserved), a 121 Nonce/Map-version field and an instance ID/Locator-status-bit field. 122 The flags provide flexibility to define how the reserved bits can be 123 used to change the definition of the LISP header. 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 |N|L|E|V|I|flags| Nonce/Map-Version | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Instance ID/Locator-Status-Bits | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Figure 1: LISP Header 133 3. Generic Protocol Extension for LISP (LISP-gpe) 135 3.1. Multi Protocol Support 137 This draft defines the following changes to the LISP header in order 138 to support multi-protocol encapsulation. 140 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 141 MUST be set to 1 to indicate the presence of the 8 bit next 142 protocol field. 144 P = 0 indicates that the payload MUST conform to LISP as defined 145 in [RFC6830]. 147 Flag bit 5 was chosen as the P bit because this flag bit is 148 currently unallocated in LISP [RFC6830]. 150 Next Protocol Field: The lower 8 bits of the first word are used to 151 carry a next protocol. This next protocol field contains the 152 protocol of the encapsulated payload packet. 154 LISP [RFC6830] uses the lower 16 bits of the first word for either 155 a nonce, an echo-nonce ([RFC6830]) or to support map-versioning 156 ([RFC6834]). These are all optional capabilities that are 157 indicated by setting the N, E, and the V bit respectively. 159 To maintain the desired data plane compatibility, when the P bit 160 is set, the N, E, and V bits MUST be set to zero. 162 A new protocol registry will be requested from IANA for the Next 163 Protocol field. This draft defines the following Next Protocol 164 values: 166 0x1 : IPv4 168 0x2 : IPv6 170 0x3 : Ethernet 172 0x4: Network Service Header 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |N|L|E|V|I|P|R|R| Reserved | Next Protocol | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Instance ID/Locator-Status-Bits | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 2: LISP-gpe Next Protocol (P=1) 184 3.2. OAM Support 186 Flag bit 7 is defined as the O bit. When the O bit is set to 1, the 187 packet is an OAM packet and OAM processing MUST occur. The OAM 188 protocol details are out of scope for this document. As with the 189 P-bit, bit 7 is currently a reserved flag in [RFC6830]. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |N|L|E|V|I|P|R|O| Reserved | Next Protocol | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Instance ID/Locator-Status-Bits | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 3: LISP-gpe OAM bit (P=1) 201 3.3. Version Bits 203 LISP-gpe bits8 and 9 are defined as version bits. The version field 204 is used to ensure backward compatibility going forward with future 205 LISP-gpe updates. 207 The initial version for LISP-gpe is 0. 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 |N|L|E|V|I|P|R|O|Ver| Reserved | Next Protocol | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Instance ID/Locator-Status-Bits | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 4: LISP-gpe Version bits (P=1) 219 4. Backward Compatibility 221 Undefined (in RFC6830) flag bits 5 and 7, LISP-gpe P and O bits, were 222 selected to ensure compatibility with existing LISP [RFC6830] 223 deployments. 225 Similarly, using P = 0 to indicate that the format of the header and 226 payload conforms to [RFC6830] ensures compatibility with existing 227 LISP hardware forwarding platforms. 229 4.1. LISP-gpe Routers to (legacy) LISP Routers 231 A LISP-gpe router MUST not encapsulate non-IP packet nor OAM packets 232 to a LISP router. A method for determining the capabilities of a 233 LISP router (gpe or "legacy") is out of the scope of this draft. 235 When encapsulating IP packets to a LISP router the P bit SHOULD be 236 set to 1 and the UDP port MUST be set to 4341. OAM bit MUST be set 237 to 0. The Next Protocol field SHOULD be 0x1 (IPv4) or 0x2 (IPv6). 238 The (legacy) LISP router will ignore the P bit and the protocol type 239 field. The (legacy) LISP router will treat the packet as a LISP 240 packet and inspect the first nibble of the payload to determine the 241 IP version. 243 When the P bit is set, the N, E, and V bits MUST be set to zero. The 244 receiving (legacy) LISP router will ignore N, E and V bits, when the 245 P bit is set. 247 4.2. (legacy) LISP Routers to LISP-gpe Routers 249 When a LISP-gpe router receives a packet from a (legacy) LISP router, 250 the P bit MUST not be set and the UDP port MUST be 4341. The payload 251 MUST be IP, and the LISP-gpe router will inspect the first nibble of 252 the payload to determine IP version. 254 4.3. Type of Service 256 When a LISP-gpe router performs Ethernet encapsulation, the inner 257 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from 258 the encapsulated frame to the Type of Service field in the outer IPv4 259 header, or in the case of IPv6 the 'Traffic Class' field. 261 4.4. VLAN Identifier (VID) 263 When a LISP-gpe router performs Ethernet encapsulation, the inner 264 header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 265 used to determine the LISP Instance ID field. 267 5. LISP-gpe Examples 269 This section provides two examples of IP protocols, and one example 270 of Ethernet encapsulated LISP-gpe using the generic extension 271 described in this document. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |N|L|E|V|I|1|0|0|0| Reserved | NP = IPv4 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Instance ID/Locator-Status-Bits | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Original IPv4 Packet | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 5: IPv4 and LISP-gpe 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |N|L|E|V|I|1|0|0|0| Reserved | NP = IPv6 | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Instance ID/Locator-Status-Bits | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Original IPv6 Packet | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 6: IPv6 and LISP-gpe 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 |N|L|E|V|I|1|0|0|0| Reserved | NP = Ethernet | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Instance ID/Locator-Status-Bits | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Original Ethernet Frame | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 7: Ethernet and LISP-gpe 309 6. Security Considerations 311 LISP-gpe security considerations are similar to the LISP security 312 considerations documented at length in LISP [RFC6830]. With LISP- 313 gpe, issues such as dataplane spoofing, flooding, and traffic 314 redirection are dependent on the particular protocol payload 315 encapsulated. 317 7. Acknowledgments 319 A special thank you goes to Dino Farinacci for his guidance and 320 detailed review. 322 8. IANA Considerations 324 IANA is requested to set up a registry of "Next Protocol". These are 325 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in 326 this draft. New values are assigned via Standards Action [RFC5226]. 328 +---------------+-------------+---------------+ 329 | Next Protocol | Description | Reference | 330 +---------------+-------------+---------------+ 331 | 0 | Reserved | This document | 332 | | | | 333 | 1 | IPv4 | This document | 334 | | | | 335 | 2 | IPv6 | This document | 336 | | | | 337 | 3 | Ethernet | This document | 338 | | | | 339 | 4 | NSH | This document | 340 | | | | 341 | 5..253 | Unassigned | | 342 +---------------+-------------+---------------+ 344 Table 1 346 There are ten bits at the beginning of the LISP-gpe header. New 347 bits are assigned via Standards Action [RFC5226]. 349 Bits 0-3 - Assigned by LISP [RFC6830] 350 Bit 4 - Instance ID (I bit) 351 Bit 5 - Next Protocol (P bit) 352 Bit 6 - Reserved 353 Bit 7 - OAM (O bit) 354 Bits 8-9 - Version 356 9. References 358 9.1. Normative References 360 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 361 August 1980. 363 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 364 September 1981. 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 370 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 371 May 2008. 373 9.2. Informative References 375 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 376 . 379 [IEEE8021Q] 380 The IEEE Computer Society, "Media Access Control (MAC) 381 Bridges and Virtual Bridge Local Area Networks", August 382 2012, . 385 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 386 October 1994. 388 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 389 Locator/ID Separation Protocol (LISP)", RFC 6830, 390 January 2013. 392 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 393 Separation Protocol (LISP) Map-Versioning", RFC 6834, 394 January 2013. 396 [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger, 397 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 398 Framework for Overlaying Virtualized Layer 2 Networks over 399 Layer 3 Networks", 2013. 401 Authors' Addresses 403 Darrel Lewis 404 Cisco Systems, Inc. 406 Email: darlewis@cisco.com 408 Puneet Agarwal 409 Broadcom 411 Email: pagarwal@broadcom.com 413 Larry Kreeger 414 Cisco Systems, Inc. 416 Email: kreeger@cisco.com 418 Fabio Maino 419 Cisco Systems, Inc. 421 Email: fmaino@cisco.com 423 Paul Quinn 424 Cisco Systems, Inc. 426 Email: paulq@cisco.com 428 Michael Smith 429 Cisco Systems, Inc. 431 Email: michsmit@cisco.com 433 Navindra Yadav 434 Cisco Systems, Inc. 436 Email: nyadav@cisco.com