idnits 2.17.1 draft-ietf-lisp-gpe-06.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 date (September 20, 2018) is 2038 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) == Outdated reference: A later version (-14) exists of draft-ietf-lisp-6834bis-02 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-18 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force F. Maino, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track J. Lemon 5 Expires: March 24, 2019 Broadcom 6 P. Agarwal 7 Innovium 8 D. Lewis 9 M. Smith 10 Cisco 11 September 20, 2018 13 LISP Generic Protocol Extension 14 draft-ietf-lisp-gpe-06 16 Abstract 18 This document describes extentions to the Locator/ID Separation 19 Protocol (LISP) Data-Plane, via changes to the LISP header, to 20 support multi-protocol encapsulation. 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 March 24, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 59 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 60 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 61 3.1. Payload Specific Transport Interactions . . . . . . . . . 6 62 3.1.1. Payload Specific Transport Interactions for Ethernet 63 Encapsulated Payloads . . . . . . . . . . . . . . . . 6 64 3.1.2. Payload Specific Transport Interactions for NSH 65 Encapsulated Payloads . . . . . . . . . . . . . . . . 7 66 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 67 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR 68 Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 8 71 5.2. Multiple Data-Planes Encapsulation Bitmap Registry . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgements and Contributors . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It 82 specifies an encapsulation format that carries IPv4 or IPv6 packets 83 (henceforth jointly referred to as IP) in a LISP header and outer 84 UDP/IP transport. 86 The LISP Data-Plane header does not specify the protocol being 87 encapsulated and therefore is currently limited to encapsulating only 88 IP packet payloads. Other protocols, most notably Virtual eXtensible 89 Local Area Network (VXLAN) [RFC7348] (which defines a similar header 90 format to LISP), are used to encapsulate Layer-2 (L2) protocols such 91 as Ethernet. 93 This document defines an extension for the LISP header, as defined in 94 [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling 95 the encapsulation of Ethernet, IP or any other desired protocol all 96 the while ensuring compatibility with existing LISP deployments. 98 A flag in the LISP header, called the P-bit, is used to signal the 99 presence of the 8-bit Next Protocol field. The Next Protocol field, 100 when present, uses 8 bits of the field allocated to the echo-noncing 101 and map-versioning features. The two features are still available, 102 albeit with a reduced length of Nonce and Map-Version. 104 LISP-GPE MAY also be used to extend the LISP Data-Plane header, that 105 has allocated all by defining a Next Protocol "shim" header that 106 implements new data plane functions not supported in the LISP header. 107 As an example, the use of the Network Service Header (NSH) with LISP- 108 GPE, can be considered an extension to add support in the Data-Plane 109 for Network Service Chaining functionalities. 111 1.1. Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 1.2. Definition of Terms 121 This document uses terms already defined in 122 [I-D.ietf-lisp-rfc6830bis]. 124 2. LISP Header Without Protocol Extensions 126 As described in Section 1, the LISP header has no protocol identifier 127 that indicates the type of payload being carried. Because of this, 128 LISP is limited to carrying IP payloads. 130 The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags 131 (some defined, some reserved), a Nonce/Map-version field and an 132 instance ID/Locator-status-bit field. The flags provide flexibility 133 to define how the various fields are encoded. Notably, Flag bit 5 is 134 the last reserved bit in the LISP header. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Instance ID/Locator-Status-Bits | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1: LISP Header 146 3. Generic Protocol Extension for LISP (LISP-GPE) 148 This document defines two changes to the LISP header in order to 149 support multi-protocol encapsulation: the introduction of the P-bit 150 and the definition of a Next Protocol field. This is shown in 151 Figure 2 and described below. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Instance ID/Locator-Status-Bits | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 2: LISP-GPE Header 163 P-Bit: Flag bit 5 is defined as the Next Protocol bit. 165 If the P-bit is clear (0) the LISP header conforms to the 166 definition in [I-D.ietf-lisp-rfc6830bis]. 168 The P-bit is set to 1 to indicate the presence of the 8 bit Next 169 Protocol field. 171 Nonce/Map-Version: In [I-D.ietf-lisp-6834bis], LISP uses the lower 172 24 bits of the first word for a nonce, an echo-nonce, or to 173 support map- versioning. These are all optional capabilities that 174 are indicated in the LISP header by setting the N, E, and V bits 175 respectively. 177 When the P-bit and the N-bit are set to 1, the Nonce field is the 178 middle 16 bits (i.e., encoded in 16 bits, not 24 bits). Note that 179 the E-bit only has meaning when the N-bit is set. 181 When the P-bit and the V-bit are set to 1, the Version fields use 182 the middle 16 bits: the Source Map-Version uses the high-order 8 183 bits, and the Dest Map-Version uses the low-order 8 bits. 185 When the P-bit is set to 1 and the N-bit and the V-bit are both 0, 186 the middle 16-bits MUST be set to 0 on transmission and ignored on 187 receipt. 189 The encoding of the Nonce field in LISP-GPE, compared with the one 190 used in [I-D.ietf-lisp-rfc6830bis] for the LISP data plane 191 encapsulation, reduces the length of the nonce from 24 to 16 bits. 192 As per [I-D.ietf-lisp-rfc6830bis], Ingress Tunnel Routers (ITRs) 193 are required to generate different nonces when sending to 194 different Routing Locators (RLOCs), but the same nonce can be used 195 for a period of time when encapsulating to the same Egress Tunnel 196 Router (ETR). The use of 16 bits nonces still allows an ITR to 197 determine to and from reachability for up to 64k RLOCs at the same 198 time. 200 Similarly, the encoding of the Source and Dest Map-Version fields, 201 compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8 202 bits. This still allows to associate 256 different versions to 203 each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping 204 to inform commmunicating ITRs and ETRs about modifications of the 205 mapping. 207 Next Protocol: The lower 8 bits of the first 32-bit word are used to 208 carry a Next Protocol. This Next Protocol field contains the 209 protocol of the encapsulated payload packet. 211 This document defines the following Next Protocol values: 213 0x1 : IPv4 215 0x2 : IPv6 217 0x3 : Ethernet 219 0x4 : Network Service Header (NSH) [RFC8300] 221 The values are tracked in an IANA registry as described in 222 Section 5.1. 224 3.1. Payload Specific Transport Interactions 226 To ensure that protocols that are encapsulated in LISP-GPE will work 227 well from a transport interaction perspective, the specification of a 228 new encapsulated payload MUST contain an analysis of how LISP-GPE 229 SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 230 Congestion Notification (ECN) bits whenever they apply to the new 231 encapsulated payload. 233 For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies 234 how to handle UDP Checksums encouraging implementors to consider UDP 235 checksum usage guidelines in section 3.4 of [RFC8085] when it is 236 desirable to protect UDP and LISP headers against corruption. Each 237 new encapsulated payloads, when registered with LISP-GPE, MUST be 238 accompanied by a similar analysis. 240 Encapsulated payloads may have a priority field that may or may not 241 be mapped to the DSCP field of the outer IP header (part of Type of 242 Service in IPv4 or Traffic Class in IPv6). Such new encapsulated 243 payloads, when registered with LISP-GPE, MUST be accompanied by an 244 analysis similar to the one performed in Section 3.1.1 of this 245 document for Ethernet payloads. 247 Encapsulated payloads may have Explicit Congestion Notification 248 mechanisms that may or may not be mapped to the outer IP header ECN 249 field. Such new encapsulated payolads, when registered with LISP- 250 GPE, MUST be accompanied by a set of guidelines derived from 251 [RFC6040]. 253 The rest of this section specifies payload specific transport 254 interactions considerations for the two new LISP-GPE encapsulated 255 payloads specified in this document: Ethernet and NSH. 257 3.1.1. Payload Specific Transport Interactions for Ethernet 258 Encapsulated Payloads 260 The UDP Checksum considerations specified in section 5.3 of 261 [I-D.ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 262 Implementors are encouraged to consider the UDP checksum usage 263 guidelines in section 3.4 of [RFC8085] when it is desirable to 264 protect UDP, LISP and Ethernet headers against corruption. 266 When a LISP-GPE router performs Ethernet encapsulation, the inner 267 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be 268 mapped from the encapsulated frame to the Type of Service field in 269 the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' 270 field. 272 When a LISP-GPE router performs Ethernet encapsulation, the inner 273 header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped 274 to, or used to determine the LISP Instance IDentifier (IID) field. 276 3.1.2. Payload Specific Transport Interactions for NSH Encapsulated 277 Payloads 279 The UDP Checksum considerations specified in section 5.3 of 280 [I-D.ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 281 Implementors are encouraged to consider the UDP checksum usage 282 guidelines in section 3.4 of [RFC8085] when it is desirable to 283 protect UDP, LISP, and NSH headers against corruption. 285 When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN 286 values MAY be mapped as specified for the Next Protocol encapsulated 287 by NSH (namely IPv4, IPv6 and Ethernet). 289 4. Backward Compatibility 291 LISP-GPE uses the same UDP destination port (4341) allocated to LISP. 293 The next Section describes a method to determine the Data-Plane 294 capabilities of a LISP ETR, based on the use of the "Multiple Data- 295 Planes" LISP Canonical Address Format (LCAF) type defined in 296 [RFC8060]. Other mechanisms can be used, including static ETR/ITR 297 (xTR) configuration, but are out of the scope of this document. 299 When encapsulating IP packets to a non LISP-GPE capable router the 300 P-bit MUST be set to 0. That is, the encapsulation format defined in 301 this document MUST NOT be sent to a router that has not indicated 302 that it supports this specification because such a router would 303 ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so 304 would misinterpret the other LISP header fields possibly causing 305 significant errors. 307 A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the 308 P-bit set to 1) to a non-LISP-GPE capable router. 310 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities 312 LISP Canonical Address Format (LCAF) [RFC8060] defines the "Multiple 313 Data-Planes" LCAF type, that can be included by an ETR in a Map-Reply 314 to encode the encapsulation formats supported by a given RLOC. In 315 this way an ITR can be made aware of the capability to support LISP- 316 GPE, as well as other encapsulations, on a given RLOC of that ETR. 318 The 3rd 32-bit word of the "Multiple Data-Planes" LCAF type, as 319 defined in [RFC8060], is a bitmap whose bits are set to one (1) to 320 represent support for each Data-Plane encapsulation. The values are 321 tracked in an IANA registry as described in Section 5.2. 323 This document defines bit 24 in the third 32-bit word of the 324 "Multiple Data-Planes" LCAF as: 326 g-Bit: The RLOCs listed in the Address Family Identifier (AFI) 327 encoded addresses in the next longword can accept LISP-GPE 328 (Generic Protocol Extension) encapsulation using destination UDP 329 port 4341 331 5. IANA Considerations 333 5.1. LISP-GPE Next Protocol Registry 335 IANA is requested to set up a registry of LISP-GPE "Next Protocol". 336 These are 8-bit values. Next Protocol values in the table below are 337 defined in this document. New values are assigned via Standards 338 Action [RFC8126]. The protocols that are being assigned values do 339 not themselves need to be IETF standards track protocols. 341 +---------------+-------------+---------------+ 342 | Next Protocol | Description | Reference | 343 +---------------+-------------+---------------+ 344 | 0 | Reserved | This Document | 345 | 1 | IPv4 | This Document | 346 | 2 | IPv6 | This Document | 347 | 3 | Ethernet | This Document | 348 | 4 | NSH | This Document | 349 | 5..255 | Unassigned | | 350 +---------------+-------------+---------------+ 352 5.2. Multiple Data-Planes Encapsulation Bitmap Registry 354 IANA is requested to set up a registry of "Multiple Data-Planes 355 Encapsulation Bitmap" to identify the encapsulations supported by an 356 ETR in the Multiple Data-Planes LCAF Type defined in [RFC8060]. The 357 bitmap is the 3rd 32-bit word of the Multiple Data-Planes LCAF type. 358 Each bit of the bitmap represents a Data-Plane Encapsulation. New 359 values are assigned via Standards Action [RFC8126]. 361 Bits 0-23 are unassigned. This document assigns bit 24 (g-bit) to 362 LISP-GPE. Bits 25-31 are assigned in [RFC8060]). 364 +----------+-------+------------------------------------+-----------+ 365 | Bit | Bit | Assigned to | Reference | 366 | Position | Name | | | 367 +----------+-------+------------------------------------+-----------+ 368 | 0-23 | | Unassigned | | 369 | 24 | g | LISP Generic Protocol Extension | This | 370 | | | (LISP-GPE) | Document | 371 | 25 | U | Generic UDP Encapsulation (GUE) | [RFC8060] | 372 | 26 | G | Generic Network Virtualization | [RFC8060] | 373 | | | Encapsulation (GENEVE) | | 374 | 27 | N | Network Virtualization - Generic | [RFC8060] | 375 | | | Routing Encapsulation (NV-GRE) | | 376 | 28 | v | VXLAN Generic Protocol Extension | [RFC8060] | 377 | | | (VXLAN-GPE) | | 378 | 29 | V | Virtual eXtensible Local Area | [RFC8060] | 379 | | | Network (VXLAN) | | 380 | 30 | l | Layer 2 LISP (LISP-L2) | [RFC8060] | 381 | 31 | L | Locator/ID Separation Protocol | [RFC8060] | 382 | | | (LISP) | | 383 +----------+-------+------------------------------------+-----------+ 385 6. Security Considerations 387 LISP-GPE security considerations are similar to the LISP security 388 considerations and mitigation techniques documented in [RFC7835]. 390 The Echo Nonce Algorithm described in [I-D.ietf-lisp-rfc6830bis] 391 relies on the nonce to detect reachability from ITR to ETR. In LISP- 392 GPE the use of a 16-bit nonce, compared with the 24-bit nonce used in 393 LISP, increases the probability of an off-path attacker to correctly 394 guess the nonce and force the ITR to believe that a non-reachable 395 RLOC is reachable. However, the use of common anti-spoofing 396 mechanisms such as uRPF prevents this form of attack. 398 LISP-GPE, as many encapsulations that use optional extensions, is 399 subject to on-path adversaries that by manipulating the g-Bit and the 400 packet itself can remove part of the payload. Typical integrity 401 protection mechanisms (such as IPsec) SHOULD be used in combination 402 with LISP-GPE by those protocol extensions that want to protect from 403 on-path attackers. 405 With LISP-GPE, issues such as data-plane spoofing, flooding, and 406 traffic redirection may depend on the particular protocol payload 407 encapsulated. 409 7. Acknowledgements and Contributors 411 A special thank you goes to Dino Farinacci for his guidance and 412 detailed review. 414 This Workking Group (WG) document originated as draft-lewis-lisp-gpe; 415 the following are its coauthors and contributors along with their 416 respective affiliations at the time of WG adoption. The editor of 417 this document would like to thank and recognize them and their 418 contributions. These coauthors and contributors provided invaluable 419 concepts and content for this document's creation. 421 o Darrel Lewis, Cisco Systems, Inc. 423 o Fabio Maino, Cisco Systems, Inc. 425 o Paul Quinn, Cisco Systems, Inc. 427 o Michael Smith, Cisco Systems, Inc. 429 o Navindra Yadav, Cisco Systems, Inc. 431 o Larry Kreeger 433 o John Lemon, Broadcom 435 o Puneet Agarwal, Innovium 437 8. References 439 8.1. Normative References 441 [I-D.ietf-lisp-6834bis] 442 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 443 Separation Protocol (LISP) Map-Versioning", draft-ietf- 444 lisp-6834bis-02 (work in progress), September 2018. 446 [I-D.ietf-lisp-rfc6830bis] 447 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 448 Cabellos-Aparicio, "The Locator/ID Separation Protocol 449 (LISP)", draft-ietf-lisp-rfc6830bis-18 (work in progress), 450 September 2018. 452 [IEEE.802.1Q_2014] 453 IEEE, "IEEE Standard for Local and metropolitan area 454 networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, 455 DOI 10.1109/ieeestd.2014.6991462, December 2014, 456 . 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, . 464 8.2. Informative References 466 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 467 Notification", RFC 6040, DOI 10.17487/RFC6040, November 468 2010, . 470 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 471 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 472 eXtensible Local Area Network (VXLAN): A Framework for 473 Overlaying Virtualized Layer 2 Networks over Layer 3 474 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 475 . 477 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 478 Separation Protocol (LISP) Threat Analysis", RFC 7835, 479 DOI 10.17487/RFC7835, April 2016, . 482 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 483 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 484 February 2017, . 486 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 487 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 488 March 2017, . 490 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 491 Writing an IANA Considerations Section in RFCs", BCP 26, 492 RFC 8126, DOI 10.17487/RFC8126, June 2017, 493 . 495 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 496 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 497 May 2017, . 499 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 500 "Network Service Header (NSH)", RFC 8300, 501 DOI 10.17487/RFC8300, January 2018, . 504 Authors' Addresses 506 Fabio Maino (editor) 507 Cisco Systems 508 San Jose, CA 95134 509 USA 511 Email: fmaino@cisco.com 513 John Lemon 514 Broadcom 515 270 Innovation Drive 516 San Jose, CA 95134 517 USA 519 Email: john.lemon@broadcom.com 521 Puneet Agarwal 522 Innovium 523 USA 525 Email: puneet@acm.org 527 Darrel Lewis 528 Cisco Systems 530 Email: darlewis@cisco.com 532 Michael Smith 533 Cisco Systems 535 Email: michsmit@cisco.com