idnits 2.17.1 draft-li-6man-enhanced-extension-header-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2020) is 1551 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: 'IANA-PN' is mentioned on line 151, but not defined == Outdated reference: A later version (-06) exists of draft-ali-spring-ioam-srv6-02 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-08 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 23, 2020 C. Xie 6 China Telecom 7 K. LEE 8 LG U+ 9 January 20, 2020 11 Enhancement of IPv6 Extension Header 12 draft-li-6man-enhanced-extension-header-01 14 Abstract 16 As SRv6 and the new services such as IOAM are progressing, more and 17 more new requirements are imposed upon the IPv6 extension headers, 18 i.e.. Hop-by-hop Options Header, Destination Options Header and 19 Routing Header. 21 This document defines new IPv6 extension headers and corresponding 22 processing procedures considering the interactions among the existing 23 IPv6 extension headers, SRH and the newly introduced IPv6 extension 24 headers. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 23, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. New Extension Headers . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Enhanced Hop-by-Hop Options Header . . . . . . . . . . . 3 69 2.2. IPv6 Metadata Header . . . . . . . . . . . . . . . . . . 4 70 3. Processing Procedures for Handling IPv6 Metadata Header . . . 6 71 3.1. Processing of IPv6 Metadata Header . . . . . . . . . . . 6 72 3.2. Interactions between IPv6 Metadata Header and Existing 73 IPv6 Extension Headers . . . . . . . . . . . . . . . . . 7 74 3.2.1. Interactions between IPv6 Metadata Header and 75 Authentication Header . . . . . . . . . . . . . . . . 7 76 3.2.2. Interactions between IPv6 Metadata Header and ESP 77 header . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.2.3. Interactions between IPv6 Metadata Header and 79 Fragment header . . . . . . . . . . . . . . . . . . . 10 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 6. Normative References . . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The basic IPv6 header and the initially defined IPv6 extension 88 headers and options are specified in [RFC8200]. SRv6 89 [I-D.ietf-spring-srv6-network-programming] introduces a new type of 90 Routing Header for IPv6, i.e. SRH 91 [I-D.ietf-6man-segment-routing-header]. For the SRv6 IOAM 92 [I-D.ali-spring-ioam-srv6], the IOAM data fields are carried in a 93 pre-allocated SRH TLV, while for the IPv6 IOAM, two types of 94 extension headers in IPv6 packets - either Hop-by-Hop Options header 95 or Destination options header are proposed to encapsulate the IOAM 96 data [I-D.ietf-ippm-ioam-ipv6-options]. 98 As SRv6 and the new services such as IOAM are progressing, more and 99 more new requirements are imposed upon the IPv6 extension headers. 100 The existing IPv6 extension headers may not be able to satisfy some 101 of the new requirements. New procedures will be required to specify 102 the processing of the new and existing IPv6 extension headers and 103 their interactions. 105 This document defines new IPv6 extension headers and corresponding 106 processing procedures considering the interactions among the existing 107 IPv6 extension headers, SRH and the newly introduced extension 108 headers. 110 2. New Extension Headers 112 According to the requirements of the new services, the following IPv6 113 extension headers are proposed. 115 2.1. Enhanced Hop-by-Hop Options Header 117 As stated in [RFC8200] together with more additional background 118 information in [RFC6564], nodes may be configured to ignore the Hop- 119 by-Hop Options header, and the packets containing a Hop-by-Hop 120 Options header may be dropped or assigned to a slow processing path. 121 In this case, the forwarding performance will be greatly reduced when 122 supporting the new services such as IOAM. 124 Nowadays the processing capability of the hardware chipset has been 125 greatly improved and kept evolving. Therefore, it becomes possible 126 to process the packets containing the Hop-by-Hop Options header at 127 wire speed, and only assign it to the slow processing path when it is 128 needed. However, currently there is still no such specification for 129 defining the above-mentioned processing procedures. 131 In order to take advantages of the advanced chipset capabilities and 132 also guarantee the compatibility with the existing IPv6 deployments, 133 a new Hop-by-Hop Options header is introduced, named Enhanced Hop-by- 134 Hop Options Header. It shares the same structure of the Hop-by-Hop 135 Options header as the one defined in [RFC8200], as shown in Figure 1. 136 A different Next Header value (TBD_1) for identifying the Enhanced 137 Hop-by-Hop Options header is required. The Options can be shared 138 with the original Hop-by-Hop Options Header. 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Next Header | Hdr Ext Len | Option Type | Opt Data Len | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 / Option Data / 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure. 1 Enhanced Hop-by-Hop Options Header 148 Next Header 8-bit selector. Identifies the type of header 149 immediately following the Hop-by-Hop Options 150 header. Uses the same values as the IPv4 151 Protocol field [IANA-PN]. 153 Hdr Ext Len 8-bit unsigned integer. Length of the 154 Hop-by-Hop Options header in 8-octet units, 155 not including the first 8 octets. 157 Option Type 8-bit identifier of the type of option. 159 Opt Data Len 8-bit unsigned integer. Length of the Option 160 Data field of this option, in octets. 162 Option Data Variable-length field. Option-Type-specific 163 data. 165 2.2. IPv6 Metadata Header 167 As path services, both IOAM and SFC need a Metadata field to record 168 its metadata information. 170 The IOAM metadata can be carried in IPv6 packets as Hop-by-Hop or 171 Destination options [I-D.ietf-ippm-ioam-ipv6-options] or SRv6 SRH TLV 172 to enhance diagnostics of IPv6/SRv6 networks. 174 The SFC metadata or context information can be shared between 175 Classifiers and SFs, and among SFs, which allows summarizing a 176 classification result in the packet itself, avoiding subsequent re- 177 classifications. Examples of metadata include classification 178 information used for policy enforcement and network context for 179 forwarding after service delivery. The SFC metadata can be carried 180 in the NSH Context Header [RFC8300] or SRv6 SRH TLV. 182 Currently these metadata have to be recorded separately which may 183 generate redundant metadata information or increase the cost of 184 process. 186 A unified metadata header, named IPv6 Metadata Header (MH), is 187 defined to be used as a container to record the metadata of IOAM, SFC 188 and other newly emerging path services in IPv6. 190 The IPv6 Metadata Header is defined as a new type of IPv6 extension 191 header shown in Figure 2, which is identified by a Next Header value 192 (TBD_2). The metadata is the information recorded by each hop for 193 specific path services. The length of the metadata is variable. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Next Header | Hdr Ext Len | Reserved | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 . . 202 . Metadata Stack (Variable) . 203 . . 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2. Metadata Header 209 Next Header 8-bit selector. Identifies the type of header 210 immediately following the IPv6 metadata 211 header. 213 Hdr Ext Len 8-bit unsigned integer. Length of the 214 IPv6 metadata header in octets. 216 Metadata Stack Variable-length field, of length such that the 217 complete IPv6 metadata header is an 218 integer multiple of 8 octets long. Contains 219 one or more type of path Service Metadata . 221 For each specific path service, i.e. IOAM/SFC, the corresponding 222 metadata is defined as shown in Figure 3. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Service Type | Length | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ~ ~ 230 | Service Metadata (variable) | 231 ~ ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 3. Service Metadata 236 Service Type 8-bit identifier of the type of 237 Metadata. 239 Length 8-bit unsigned integer. Length of the 240 Service Metadata field, in octets. 242 Metadata Variable-length field. Service-Type-specific data. 244 3. Processing Procedures for Handling IPv6 Metadata Header 246 With the introduction of the IPv6 Metadata Header, the processing of 247 the IPv6 Authentication Header (AH), Encapsulating Security Payload 248 header (ESP), and Fragment header (FH) need to be specified. 250 The processing of the IPv6 AH when the SRH is present in the same 251 packet is described in [I-D.herbert-ipv6-srh-ah]. The processing 252 procedures also need to be specified when the SRH is present in the 253 case of SRv6. 255 3.1. Processing of IPv6 Metadata Header 257 As specified in [RFC8200], when more than one extension header is 258 used in the same packet, it is recommended that those headers appear 259 in the following order: 261 IPv6 header 262 Hop-by-Hop Options header 263 Destination Options header 264 Routing header 265 Option 1----> 266 Fragment header 267 Authentication header 268 Encapsulating Security Payload header 269 Destination Options header 270 Option 2----> 271 Upper-Layer header 273 In the incremental tracing mode of IOAM, as the number of nodes 274 traversed by the IPv6 packets increases, the recorded IOAM 275 information will increase accordingly, which will increase the length 276 of the Metadata field. 278 If the IPv6 MH is placed before RH (SRH for SRv6), it will cause 279 increasing difficulties in reading the following SRH and thereby 280 reduce the forwarding performance of the data plane greatly. 281 Therefore, two options in the IPv6 extension headers are recommended 282 for inserting the IPv6 MH. The different locations for inserting the 283 IPv6 MH will also impact the processing of the AH, ESP, and FH, which 284 will be discussed in the following section. 286 Option 1: The IPv6 Metadata Header is inserted after the RH but 287 before FH. 289 Option 2: The IPv6 Metadata Header is placed as the last IPv6 290 extension header, i.e. after the second Destination Options header 291 but before the Upper-Layer header. 293 3.2. Interactions between IPv6 Metadata Header and Existing IPv6 294 Extension Headers 296 When the IPv6 Metadata is presented, the processing of AH, ESP, and 297 FH need to be specified. 299 3.2.1. Interactions between IPv6 Metadata Header and Authentication 300 Header 302 AH [RFC4302] is used to authenticate the preceding IPv6 header and 303 extension headers in a packet. Authentication is performed by 304 computing an Integrity Check Value (ICV) over the covered headers and 305 comparing the computed value to that contained in the ICV field of 306 the AH header. Both the sender and receiver (the final destination 307 in the case that a routing header is present) MUST independently and 308 deterministically perform the same computation over the same data. 310 When the IPv6 Metadata Header is presented, the processing of AH 311 needs to be specified. As specified in [RFC4302], AH may be employed 312 in two ways: transport mode or tunnel mode. See the Security 313 Architecture document [RFC4301] for a description of when each should 314 be used. 316 3.2.1.1. Transport Mode Processing 318 In transport mode, AH is inserted after the IP header and before a 319 next layer protocol (e.g., TCP, UDP, ICMP, etc.) or before any other 320 IPsec headers that have already been inserted. 322 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 323 should appear after hop-by-hop, routing, and fragmentation extension 324 headers. The destination options extension header(s) could appear 325 before or after or both before and after the AH header depending on 326 the semantics desired. 328 Since the IPv6 MH will be modified during transit (i.e. it is 329 mutable) and its value at the (IPsec) receiver is not predictable, 330 the value of the field is set to zero for purposes of the AH ICV 331 computation according to [RFC4302]. 333 When the IPv6 MH is introduced, the following diagram illustrates the 334 positioning of the IPv6 Metadata Header as well as the SRH in the AH 335 transport mode. 337 ------------------------------------------------------------ 338 | |hop-by-hop, dest*, | | dest | | | 339 |orig IP hdr |routing(SRH),MH,FH | AH | opt* | TCP | Data | 340 ------------------------------------------------------------ 341 |<--- mutable field processing -->|<-- immutable fields -->| 342 |<---- authenticated except for mutable fields ----------->| 344 * = if present, could be before AH, after AH, or both 346 3.2.1.2. Tunnel Mode Processing 348 In tunnel mode, the "inner" IP header carries the ultimate (IP) 349 source and destination addresses, while an "outer" IP header contains 350 the addresses of the IPsec "peers," e.g., addresses of security 351 gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 352 over IPv4 and IPv4 over IPv6. 354 In tunnel mode, AH protects the entire inner IP packet, including the 355 entire inner IP header. The position of AH in tunnel mode, relative 356 to the outer IP header, is the same as for AH in transport mode. The 357 following diagram illustrates the positioning of the IPv6 Metadata 358 Header as well as the SRH in the AH tunnel mode. 360 -------------------------------------------------------------- 361 | | ext hdrs*| | | ext hdrs*| | | 362 |new IP hdr*|(SRH, MH) | AH |orig IP hdr*|if present|TCP|Data| 363 -------------------------------------------------------------- 364 |<--- mutable field -->|<--------- immutable fields -------->| 365 | processing | 366 |<-- authenticated except for mutable fields in new IP hdr ->| 368 * = if present, construction of outer IP hdr/extensions and 369 modification of inner IP hdr/extensions is discussed in 370 the Security Architecture document. 372 3.2.2. Interactions between IPv6 Metadata Header and ESP header 374 When the IPv6 Metadata Header is presented, the processing of ESP 375 needs to be specified. As specified in [RFC4303], ESP may be 376 employed in two ways: transport mode or tunnel mode. 378 3.2.2.1. Transport Mode Processing 380 In transport mode, ESP is inserted after the IP header and before a 381 next layer protocol, e.g., TCP, UDP, ICMP, etc. 383 In the IPv6 context, ESP is viewed as an end-to-end payload, and 384 thus, as specified in [RFC4303], should appear after hop-by-hop, 385 routing, and fragmentation extension headers. Because ESP protects 386 only fields after the ESP header, it recommends that the destination 387 options header(s) is placed after the ESP header. 389 When the IPv6 MH is introduced, with option 2 in Section 3.1, the 390 IPv6 MH will be placed after the second DOH thereby encrypted, while 391 with option1, it will not be encrypted. 393 The following diagram illustrates the positioning of the IPv6 394 Metadata Header as well as the SRH in the ESP transport mode. 396 Option 1 397 ----------------------------------------------------------- 398 | orig |hop-by-hop,dest*, | |dest| | | ESP | ESP| 399 |IP hdr|routing(SRH),MH,FH |ESP|opt*|TCP|Data|Trailer| ICV| 400 ----------------------------------------------------------- 401 |<--- encryption ---->| 402 |<------ integrity ------>| 404 Option 2 405 --------------------------------------------------------------- 406 | orig |hop-by-hop,dest*,| |dest| | | | ESP | ESP| 407 |IP hdr|routing(SRH),FH. |ESP|opt*| MH | TCP|Data|Trailer| ICV| 408 --------------------------------------------------------------- 409 |<------ encryption ------->| 410 |<---------- integrity -------->| 412 * = if present, could be before ESP, after ESP, or both 414 3.2.2.2. Tunnel Mode Processing 416 In tunnel mode, the "inner" IP header carries the ultimate (IP) 417 source and destination addresses, while an "outer" IP header contains 418 the addresses of the IPsec "peers", e.g., addresses of security 419 gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 420 over IPv4 and IPv4 over IPv6. 422 In tunnel mode, ESP protects the entire inner IP packet, including 423 the entire inner IP header. The position of ESP in tunnel mode, 424 relative to the outer IP header, is the same as for ESP in transport 425 mode. The following diagram illustrates the positioning of the IPv6 426 Metadata Header as well as the SRH in the ESP tunnel mode. 428 ------------------------------------------------------------------------ 429 | new* | new ext hdrs | | orig*| orig ext hdrs | | | ESP | ESP| 430 |IP hdr| (SRH, MH)* |ESP|IP hdr| (SRH,MH) * |TCP|Data|Trailer| ICV| 431 ------------------------------------------------------------------------ 432 |<------------ encryption ------------->| 433 |<--------------- integrity --------------->| 435 * = if present, construction of outer IP hdr/extensions and 436 modification of inner IP hdr/extensions is discussed in 437 the Security Architecture document 439 3.2.3. Interactions between IPv6 Metadata Header and Fragment header 441 When the IPv6 Metadata is presented, the processing of FH needs to be 442 specified. 444 Note that in AH/ESP transport mode, for "bump-in-the-stack" or "bump- 445 in- the-wire" implementations, as defined in the Security 446 Architecture document, inbound and outbound IP fragments may require 447 an IPsec implementation to perform extra IP reassembly/fragmentation 448 in order to both conform to this specification and provide 449 transparent IPsec support. Special care is required to perform such 450 operations within these implementations when multiple interfaces are 451 in use. 453 4. IANA Considerations 455 This draft requests the following IPv6 Extension Header Type 456 assignments in the Assigned Internet Protocol Numbers registry. 458 https://www.iana.org/assignments/protocol-numbers/protocol- 459 numbers.xhtml 461 https://www.iana.org/assignments/ipv6-parameters/ipv6- 462 parameters.xhtml#extension-header 464 Protocol Number Description Reference 465 --------------------------------------------------------------------- 466 TBD_1 Enhanced Hop-by-Hop Options header [This draft] 467 TBD_2 IPv6 Metadata Header [This draft] 469 5. Security Considerations 471 As this document describes new extension headers for IPv6, these are 472 similar to the security considerations of [RFC8200]. 474 This document describes the encapsulation of IOAM and SFC metadata 475 fields in IPv6. Security considerations of the specific IOAM and SFC 476 metadata fields are described in [I-D.ietf-ippm-ioam-data] and 477 [RFC8300], respectively. 479 6. Normative References 481 [I-D.ali-spring-ioam-srv6] 482 Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Kumar, 483 N., Pignataro, C., Li, C., Chen, M., and G. Dawra, 484 "Segment Routing Header encapsulation for In-situ OAM 485 Data", draft-ali-spring-ioam-srv6-02 (work in progress), 486 November 2019. 488 [I-D.herbert-ipv6-srh-ah] 489 Herbert, T., "IPv6 Authentication Header with Segment 490 Routing Header Processing", draft-herbert-ipv6-srh-ah-00 491 (work in progress), May 2019. 493 [I-D.ietf-6man-segment-routing-header] 494 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 495 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 496 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 497 progress), October 2019. 499 [I-D.ietf-ippm-ioam-data] 500 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 501 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 502 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 503 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 504 ietf-ippm-ioam-data-08 (work in progress), October 2019. 506 [I-D.ietf-ippm-ioam-ipv6-options] 507 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 508 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 509 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 510 "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 511 ipv6-options-00 (work in progress), September 2019. 513 [I-D.ietf-spring-srv6-network-programming] 514 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 515 Matsushima, S., and Z. Li, "SRv6 Network Programming", 516 draft-ietf-spring-srv6-network-programming-08 (work in 517 progress), January 2020. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, 521 DOI 10.17487/RFC2119, March 1997, 522 . 524 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 525 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 526 December 2005, . 528 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 529 DOI 10.17487/RFC4302, December 2005, 530 . 532 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 533 RFC 4303, DOI 10.17487/RFC4303, December 2005, 534 . 536 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 537 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 538 RFC 6564, DOI 10.17487/RFC6564, April 2012, 539 . 541 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 542 (IPv6) Specification", STD 86, RFC 8200, 543 DOI 10.17487/RFC8200, July 2017, 544 . 546 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 547 "Network Service Header (NSH)", RFC 8300, 548 DOI 10.17487/RFC8300, January 2018, 549 . 551 Authors' Addresses 553 Zhenbin Li 554 Huawei Technologies 555 Huawei Bld., No.156 Beiqing Rd. 556 Beijing 100095 557 China 559 Email: lizhenbin@huawei.com 561 Shuping Peng 562 Huawei Technologies 563 Huawei Bld., No.156 Beiqing Rd. 564 Beijing 100095 565 China 567 Email: pengshuping@huawei.com 569 Chongfeng Xie 570 China Telecom 571 Beiqijia Town, Changping District 572 Beijing 573 China 575 Email: xiechf.bri@huawei.com 577 Kihoon LEE 578 LG U+ 579 71, Magokjungang 8-ro, Gangseo-gu 580 Seoul 581 Korea 583 Email: soho8416@guplus.co.kr