idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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. -- The document date (January 24, 2018) is 2281 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE8021Q' is mentioned on line 207, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) ** Downref: Normative reference to an Informational RFC: RFC 7348 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-08 == Outdated reference: A later version (-02) exists of draft-lemon-vxlan-gpe-gbp-01 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Lewis 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Lemon 5 Expires: July 28, 2018 Broadcom 6 P. Agarwal 7 Innovium 8 L. Kreeger 10 P. Quinn 11 M. Smith 12 N. Yadav 13 F. Maino, Ed. 14 Cisco 15 January 24, 2018 17 LISP Generic Protocol Extension 18 draft-ietf-lisp-gpe-00 20 Abstract 22 This draft describes extending the Locator/ID Separation Protocol 23 (LISP), via changes to the LISP header, to support multi-protocol 24 encapsulation. 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 July 28, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 63 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 64 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 3 65 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 66 4.1. Type of Service . . . . . . . . . . . . . . . . . . . . . 5 67 4.2. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 8.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 LISP, as defined in [RFC6830] and extended in 79 [I-D.ietf-lisp-rfc6830bis], defines an encapsulation format that 80 carries IPv4 or IPv6 (henceforth referred to as IP) packets in a LISP 81 header and outer UDP/IP transport. 83 The LISP header does not specify the protocol being encapsulated and 84 therefore is currently limited to encapsulating only IP packet 85 payloads. Other protocols, most notably VXLAN [RFC7348] (which 86 defines a similar header format to LISP), are used to encapsulate L2 87 protocols such as Ethernet. 89 This document defines an extension for the LISP header, as defined in 90 [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling 91 the encapsulation of Ethernet, IP or any other desired protocol all 92 the while ensuring compatibility with existing LISP deployments. 94 A flag in the LISP header, called the P-bit, is used to signal the 95 presence of the 8-bit Next Protocol field. The Next Protocol field, 96 when present, uses 8 bits of the field allocated to the echo-noncing 97 and map-versioning features. The two features are still available, 98 albeit with a reduced length of Nonce and Map-Version. 100 1.1. Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 1.2. Definition of Terms 108 This document uses terms already defined in 109 [I-D.ietf-lisp-rfc6830bis]. 111 2. LISP Header Without Protocol Extensions 113 As described in the introduction, the LISP header has no protocol 114 identifier that indicates the type of payload being carried. Because 115 of this, LISP is limited to carry IP payloads. 117 The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags 118 (some defined, some reserved), a Nonce/Map-version field and an 119 instance ID/Locator-status-bit field. The flags provide flexibility 120 to define how the various fields are encoded. Notably, Flag bit 5 is 121 the last reserved bit in the LISP header. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Instance ID/Locator-Status-Bits | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 LISP Header 133 3. Generic Protocol Extension for LISP (LISP-GPE) 135 This document defines the following changes to the LISP header in 136 order to support multi-protocol encapsulation: 138 P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit 139 MUST be set to 1 to indicate the presence of the 8 bit next 140 protocol field. 142 P = 0 indicates that the payload MUST conform to LISP as defined 143 in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit 144 because this flag bit is currently unallocated. 146 Next Protocol: The lower 8 bits of the first 32-bit word are used to 147 carry a Next Protocol. This Next Protocol field contains the 148 protocol of the encapsulated payload packet. 150 LISP uses the lower 24 bits of the first word for either a nonce, 151 an echo-nonce, or to support map-versioning [RFC6834]. These are 152 all optional capabilities that are indicated in the LISP header by 153 setting the N, E, and the V bit respectively. 155 When the P-bit and the N-bit are set to 1, the Nonce field is the 156 middle 16 bits. 158 When the P-bit and the V-bit are set to 1, the Version field is 159 the middle 16 bits. 161 When the P-bit is set to 1 and the N-bit and the V-bit are both 0, 162 the middle 16-bits are set to 0. 164 This draft defines the following Next Protocol values: 166 0x1 : IPv4 168 0x2 : IPv6 170 0x3 : Ethernet 172 0x4 : Network Service Header [I-D.ietf-sfc-nsh] 174 0x6: Group-Based Policy (GBP) [I-D.lemon-vxlan-gpe-gbp]. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Instance ID/Locator-Status-Bits | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 LISP-GPE Header 186 4. Backward Compatibility 188 LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 190 A LISP-GPE router MUST not encapsulate non-IP packets to a LISP 191 router. A method for determining the capabilities of a LISP router 192 (GPE or "legacy") is out of the scope of this draft. 194 When encapsulating IP packets to a LISP "legacy" router the P bit 195 MUST be set to 0. 197 4.1. Type of Service 199 When a LISP-GPE router performs Ethernet encapsulation, the inner 200 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from 201 the encapsulated frame to the Type of Service field in the outer IPv4 202 header, or in the case of IPv6 the 'Traffic Class' field. 204 4.2. VLAN Identifier (VID) 206 When a LISP-GPE router performs Ethernet encapsulation, the inner 207 header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or 208 used to determine the LISP Instance ID field. 210 5. IANA Considerations 212 IANA is requested to set up a registry of LISP-GPE "Next Protocol". 213 These are 8-bit values. Next Protocol values in the table below are 214 defined in this draft. New values are assigned via Standards Action 215 [RFC5226]. 217 +---------------+-------------+---------------+ 218 | Next Protocol | Description | Reference | 219 +---------------+-------------+---------------+ 220 | 0 | Reserved | This Document | 221 | 1 | IPv4 | This Document | 222 | 2 | IPv6 | This Document | 223 | 3 | Ethernet | This Document | 224 | 4 | NSH | This Document | 225 | 5 | Reserved | | 226 | 6 | GBP | This Document | 227 | 7 | Reserved | | 228 | 8..255 | Unassigned | | 229 +---------------+-------------+---------------+ 231 6. Security Considerations 233 LISP-GPE security considerations are similar to the LISP security 234 considerations documented at length in [I-D.ietf-lisp-rfc6830bis]. 235 With LISP-GPE, issues such as dataplane spoofing, flooding, and 236 traffic redirection may depend on the particular protocol payload 237 encapsulated. 239 7. Acknowledgements 241 A special thank you goes to Dino Farinacci for his guidance and 242 detailed review. 244 8. References 246 8.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, . 253 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 254 IANA Considerations Section in RFCs", RFC 5226, 255 DOI 10.17487/RFC5226, May 2008, . 258 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 259 Locator/ID Separation Protocol (LISP)", RFC 6830, 260 DOI 10.17487/RFC6830, January 2013, . 263 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 264 Separation Protocol (LISP) Map-Versioning", RFC 6834, 265 DOI 10.17487/RFC6834, January 2013, . 268 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 269 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 270 eXtensible Local Area Network (VXLAN): A Framework for 271 Overlaying Virtualized Layer 2 Networks over Layer 3 272 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 273 . 275 8.2. Informative References 277 [I-D.ietf-lisp-rfc6830bis] 278 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 279 Cabellos-Aparicio, "The Locator/ID Separation Protocol 280 (LISP)", draft-ietf-lisp-rfc6830bis-08 (work in progress), 281 January 2018. 283 [I-D.ietf-sfc-nsh] 284 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 285 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 286 November 2017. 288 [I-D.lemon-vxlan-gpe-gbp] 289 Lemon, J., Maino, F., and M. Smith, "Group Policy Encoding 290 with VXLAN-GPE", draft-lemon-vxlan-gpe-gbp-01 (work in 291 progress), December 2017. 293 Authors' Addresses 295 Darrel Lewis 296 Cisco Systems 298 Email: darlewis@cisco.com 300 John Lemon 301 Broadcom 302 3151 Zanker Road 303 San Jose, CA 95134 304 USA 306 Email: john.lemon@broadcom.com 308 Puneet Agarwal 309 Innovium 310 USA 312 Email: puneet@acm.org 314 Larry Kreeger 315 USA 317 Email: lkreeger@gmail.com 318 Paul Quinn 319 Cisco Systems 321 Email: pquinn@cisco.com 323 Michael Smith 324 Cisco Systems 326 Email: michsmit@cisco.com 328 Navindra Yadav 329 Cisco Systems 331 Email: nyadav@cisco.com 333 Fabio Maino (editor) 334 Cisco Systems 335 San Jose, CA 95134 336 USA 338 Email: fmaino@cisco.com