idnits 2.17.1 draft-lewis-lisp-gpe-00.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 (August 27, 2013) is 3894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0768' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC0791' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 279, 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 L. Kreeger 4 Intended status: Informational F. Maino 5 Expires: February 28, 2014 P. Quinn 6 Cisco Systems, Inc. 7 M. Smith 8 N. Yadav 9 Insieme Networks 10 August 27, 2013 12 LISP Generic Protocol Extension 13 draft-lewis-lisp-gpe-00.txt 15 Abstract 17 This draft describes a mechanism for adding generalized multi- 18 protocol support to the Locator/ID Separation Protocol (LISP) 19 [RFC6830]. Protocol identification is carried in the LISP header and 20 is used to describe the encapsulated payload. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 28, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. LISP Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Generic Protocol Extension for LISP (LISP-gpe) . . . . . . . . 5 59 3.1. LISP-gpe Header . . . . . . . . . . . . . . . . . . . . . 5 60 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 61 4.1. LISP-gpe Routers to (legacy) LISP Routers . . . . . . . . 6 62 4.2. (legacy) LISP Routers to LISP-gpe Routers . . . . . . . . 6 63 4.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6 65 5. LISP-gpe Examples . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 LISP [RFC6830] defines an encapsulation format that carries IPv4 or 77 IPv6 (henceforth referred to as IP) packets in a LISP header and 78 outer UDP/IP transport. The LISP header does not specify the 79 protocol being encapsulated and therefore is currently limited to 80 encapsulating only IP packet payloads. Other protocols, most notably 81 VXLAN [VXLAN] (which defines a similar header format to LISP), are 82 used to encapsulate L2 protocols such as Ethernet. LISP [RFC6830] 83 can be extended to indicate the inner protocol, enabling the 84 encapsulation of Ethernet, IP or any other desired protocol all the 85 while ensuring compatibility with existing LISP [RFC6830] 86 deployments. 88 This document describes extending LISP ([RFC6830]) to support 89 additional payload types beyond IP packets. To support this 90 capability, two elements of the existing LISP header are modified. 92 1. A flag bit is allocated, and set in the LISP header. 94 2. A 16 bit Protocol Type field is present in the LISP header. 96 These changes allow for the LISP header to support many different 97 types of payloads. Backward compatibility with existing LISP tunnel 98 routers is discussed in section 4. 100 2. LISP Header 102 As described in the introduction, the LISP header has no protocol 103 identifier that indicates the type of payload being carried by LISP. 104 Because of this, LISP is limited to an IP payload. 106 The LISP header contains flags (some defined, some reserved), a 107 Nonce/Map-version field and an instance ID/Locator-status-bit field. 108 The flags provide flexibility to define how the reserved bits can be 109 used to change the definition of the LISP header. 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 |N|L|E|V|I|flags| Nonce/Map-Version | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Instance ID/Locator-Status-Bits | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 Figure 1: LISP Header 119 3. Generic Protocol Extension for LISP (LISP-gpe) 121 3.1. LISP-gpe Header 123 This draft defines two changes to the LISP header in order to support 124 multi-protocol encapsulation. 126 P Bit: Flag bit 5 is defined as the P bit. The P bit MUST be set to 127 1 to indicate the presence of the 16 bit protocol type field in 128 the lower 16 bits of the first word. 130 P = 0 indicates that the payload MUST conform to LISP as defined 131 in [RFC6830]. 133 Flag bit 5 was chosen as the P bit because this flag bit is 134 currently unallocated in LISP [RFC6830]. 136 Protocol Type Field: The lower 16 bits of the first word are used to 137 carry a protocol type. This protocol type field contains the 138 protocol, as defined in in [RFC1700] and in [ETYPES], of the 139 encapsulated payload packet. 141 LISP [RFC6830] uses the lower 16 bits of the first word for either 142 a nonce, an echo-nonce ([RFC6830]) or to support map-versioning 143 ([RFC6834]). These are all optional capabilities that are 144 indicated by setting the N, E, and the V bit respectively. 146 To maintain the desired data plane compatibility, when the P bit 147 is set, the N, E, and V bits MUST be set to zero. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Source Port = xxxx | Dest Port = 4341 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | UDP Length | UDP Checksum | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |N|L|E|V|I|P|R|R| Reserved |Nonce/Map-Version/Protocol-Type| 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Instance ID/Locator-Status-Bits | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 2: UDP + LISP-gpe 163 4. Backward Compatibility 165 An undefined (in RFC6830) flag bit, 5, was selected to ensure 166 compatibility with existing LISP [RFC6830] deployments. 168 Similarly, using P = 0 to indicate that the format of the header and 169 payload conforms to [RFC6830] ensures compatibility with existing 170 LISP hardware forwarding platforms. 172 4.1. LISP-gpe Routers to (legacy) LISP Routers 174 A LISP-gpe router MUST not encapsulate non-IP packets to a LISP 175 router. A method for determining the capabilities of a LISP router 176 (gpe or "legacy") is out of the scope of this draft. 178 When encapsulating IP packets to a LISP router the P bit SHOULD be 179 set to 1 and the UDP port MUST be set to 4341. The Protocol Type 180 field SHOULD be 0x800 or 0x86DD. The (legacy) LISP router will 181 ignore the P bit and the protocol type field. The (legacy) LISP 182 router will treat the packet as a LISP packet and inspect the first 183 nibble of the payload to determine the IP version. 185 When the P bit is set, the N, E, and V bits MUST be set to zero. The 186 receiving (legacy) LISP router will ignore N, E and V bits, when the 187 P bit is set. 189 4.2. (legacy) LISP Routers to LISP-gpe Routers 191 When a LISP-gpe router receives a packet from a (legacy) LISP router, 192 the P bit MUST not be set and the UDP port MUST be 4341. The payload 193 MUST be IP, and the LISP-gpe router will inspect the first nibble of 194 the payload to determine IP version. 196 4.3. Type of Service 198 When a LISP-gpe router performs Ethernet encapsulation, the inner 199 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from 200 the encapsulated frame to the Type of Service field in the outer IPv4 201 header, or in the case of IPv6 the 'Traffic Class' field. 203 4.4. VLAN Identifier (VID) 205 When a LISP-gpe router performs Ethernet encapsulation, the inner 206 header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 207 used to determine the LISP Instance ID field. 209 5. LISP-gpe Examples 211 This section provides two examples of IP protocols, and one example 212 of Ethernet encapsulated LISP-gpe using the generic extension 213 described in this document. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |N|L|E|V|I|1|R|R| Reserved | 0x800 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Instance ID/Locator-Status-Bits | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Original IPv4 Packet | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 3: IPv4 and LISP-gpe 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |N|L|E|V|I|1|R|R| Reserved | 0x86DD | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Instance ID/Locator-Status-Bits | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Original IPv6 Packet | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 4: IPv6 and LISP-gpe 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |N|L|E|V|I|1|R|R| Reserved | 0x6558 | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Instance ID/Locator-Status-Bits | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Original Ethernet Frame | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 5: Ethernet and LISP-gpe 251 6. Security Considerations 253 LISP-gpe security considerations are similar to the LISP security 254 considerations documented at length in LISP [RFC6830]. With LISP- 255 gpe, issues such as dataplane spoofing, flooding, and traffic 256 redirection are dependent on the particular protocol payload 257 encapsulated. 259 7. Acknowledgments 261 A special thank you goes to Dino Farinacci for his guidance and 262 detailed review. 264 8. IANA Considerations 266 This document creates no new requirements on IANA namespaces 267 [RFC5226]. 269 9. References 271 9.1. Normative References 273 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 274 August 1980. 276 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 277 September 1981. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 283 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 284 May 2008. 286 9.2. Informative References 288 [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, 289 . 292 [IEEE8021Q] 293 The IEEE Computer Society, "Media Access Control (MAC) 294 Bridges and Virtual Bridge Local Area Networks", August 295 2012, . 298 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 299 October 1994. 301 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 302 Locator/ID Separation Protocol (LISP)", RFC 6830, 303 January 2013. 305 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 306 Separation Protocol (LISP) Map-Versioning", RFC 6834, 307 January 2013. 309 [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger, 310 L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 311 Framework for Overlaying Virtualized Layer 2 Networks over 312 Layer 3 Networks", 2013. 314 Authors' Addresses 316 Darrel Lewis 317 Cisco Systems, Inc. 319 Email: darlewis@cisco.com 321 Larry Kreeger 322 Cisco Systems, Inc. 324 Email: kreeger@cisco.com 326 Fabio Maino 327 Cisco Systems, Inc. 329 Email: kreeger@cisco.com 331 Paul Quinn 332 Cisco Systems, Inc. 334 Email: paulq@cisco.com 336 Michael Smith 337 Insieme Networks 339 Email: michsmit@insiemenetworks.com 341 Navindra Yadav 342 Insieme Networks 344 Email: nyadav@insiemenetworks.com