idnits 2.17.1 draft-li-6man-enhanced-extension-header-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 : ---------------------------------------------------------------------------- ** 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 (July 8, 2019) is 1753 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 149, but not defined == Outdated reference: A later version (-03) exists of draft-ali-6man-spring-srv6-oam-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 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: January 9, 2020 July 8, 2019 7 Enhancement of IPv6 Extension Header 8 draft-li-6man-enhanced-extension-header-00 10 Abstract 12 As SRv6 and the new services such as SFC and IOAM are progressing, 13 more and more new requirements are imposed upon the IPv6 extension 14 headers, i.e.. Hop-by-hop Options Header, Destination Options Header 15 and Routing Header. 17 This document defines new IPv6 extension headers and corresponding 18 processing procedures considering the interactions among the existing 19 IPv6 extension headers, SRH and the newly introduced IPv6 extension 20 headers. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 9, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. New Extension Headers . . . . . . . . . . . . . . . . . . . . 3 64 2.1. Enhanced Hop-by-Hop Options Header . . . . . . . . . . . 3 65 2.2. IPv6 Metadata Header . . . . . . . . . . . . . . . . . . 4 66 3. Processing Procedures for Handling IPv6 Metadata Header . . . 6 67 3.1. Processing of IPv6 Metadata Header . . . . . . . . . . . 6 68 3.2. Interactions between IPv6 Metadata Header and Existing 69 IPv6 Extension Headers . . . . . . . . . . . . . . . . . 7 70 3.2.1. Interactions between IPv6 Metadata Header and 71 Authentication Header . . . . . . . . . . . . . . . . 7 72 3.2.2. Interactions between IPv6 Metadata Header and ESP 73 header . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2.3. Interactions between IPv6 Metadata Header and 75 Fragment header . . . . . . . . . . . . . . . . . . . 10 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 6. Normative References . . . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The basic IPv6 header and the initially defined IPv6 extension 84 headers and options are specified in [RFC8200]. SRv6 85 [I-D.ietf-spring-srv6-network-programming] introduces a new type of 86 Routing Header for IPv6, i.e. SRH 87 [I-D.ietf-6man-segment-routing-header]. For supporting the SRv6 88 service programming SFC [I-D.xuclad-spring-sr-service-programming], 89 SRH TLV is used to carry the Service Metadata [RFC8300]. For the 90 SRv6 IOAM [I-D.ali-6man-spring-srv6-oam], the IOAM data fields are 91 carried in a pre-allocated SRH TLV, while for the IPv6 IOAM, two 92 types of extension headers in IPv6 packets - either Hop-by-Hop 93 Options header or Destination options header are proposed to 94 encapsulate the IOAM data [I-D.ioametal-ippm-6man-ioam-ipv6-options]. 96 As SRv6 and the new services such as SFC and iOAM are progressing, 97 more and more new requirements are imposed upon the IPv6 extension 98 headers. The existing IPv6 extension headers may not be able to 99 satisfy some of the new requirements. New procedures will be 100 required to specify the processing of the new and existing IPv6 101 extension headers and their interactions. 103 This document defines new IPv6 extension headers and corresponding 104 processing procedures considering the interactions among the existing 105 IPv6 extension headers, SRH and the newly introduced extension 106 headers. 108 2. New Extension Headers 110 According to the requirements of the new services, the following IPv6 111 extension headers are proposed. 113 2.1. Enhanced Hop-by-Hop Options Header 115 As stated in [RFC8200] together with more additional background 116 information in [RFC6564], nodes may be configured to ignore the Hop- 117 by-Hop Options header, and the packets containing a Hop-by-Hop 118 Options header may be dropped or assigned to a slow processing path. 119 In this case, the forwarding performance will be greatly reduced when 120 supporting the new services such as IOAM. 122 Nowadays the processing capability of the hardware chipset has been 123 greatly improved and kept evolving. Therefore, it becomes possible 124 to process the packets containing the Hop-by-Hop Options header at 125 wire speed, and only assign it to the slow processing path when it is 126 needed. However, currently there is still no such specification for 127 defining the above-mentioned processing procedures. 129 In order to take advantages of the advanced chipset capabilities and 130 also guarantee the compatibility with the existing IPv6 deployments, 131 a new Hop-by-Hop Options header is introduced, named Enhanced Hop-by- 132 Hop Options Header. It shares the same structure of the Hop-by-Hop 133 Options header as the one defined in [RFC8200], as shown in Figure 1. 134 A different Next Header value (TBD_1) for identifying the Enhanced 135 Hop-by-Hop Options header is required. The Options can be shared 136 with the original Hop-by-Hop Options Header. 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Next Header | Hdr Ext Len | Option Type | Opt Data Len | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 / Option Data / 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure. 1 Enhanced Hop-by-Hop Options Header 146 Next Header 8-bit selector. Identifies the type of header 147 immediately following the Hop-by-Hop Options 148 header. Uses the same values as the IPv4 149 Protocol field [IANA-PN]. 151 Hdr Ext Len 8-bit unsigned integer. Length of the 152 Hop-by-Hop Options header in 8-octet units, 153 not including the first 8 octets. 155 Option Type 8-bit identifier of the type of option. 157 Opt Data Len 8-bit unsigned integer. Length of the Option 158 Data field of this option, in octets. 160 Option Data Variable-length field. Option-Type-specific 161 data. 163 2.2. IPv6 Metadata Header 165 The IOAM metadata can be carried in IPv6 packets as Hop-by-Hop or 166 Destination options [I-D.ioametal-ippm-6man-ioam-ipv6-options] or 167 SRv6 SRH TLV to enhance diagnostics of IPv6/SRv6 networks. 169 The SFC metadata or context information can be shared between 170 Classifiers and SFs, and among SFs, which allows summarizing a 171 classification result in the packet itself, avoiding subsequent re- 172 classifications. Examples of metadata include classification 173 information used for policy enforcement and network context for 174 forwarding after service delivery. The SFC metadata can be carried 175 in the NSH Context Header [RFC8300] or SRv6 SRH TLV, 177 As described above, both SFC and IOAM need a Metadata field to record 178 its metadata information. Currently these metadata have to be 179 recorded separately which may generate redundant metadata information 180 or increase the cost of process. 182 A unified metadata header, named IPv6 Metadata Header (MH), is 183 defined to be used as a container to record the metadata of SFC, IOAM 184 and other newly emerging path services in IPv6. 186 The IPv6 Metadata Header is defined as a new type of IPv6 extension 187 header shown in Figure 2, which is identified by a Next Header value 188 (TBD_2). The metadata is the information recorded by each hop for 189 specific path services. The length of the metadata is variable. 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 | Next Header | Hdr Ext Len | Reserved | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 . . 198 . Metadata Stack (Variable) . 199 . . 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 2. Metadata Header 205 Next Header 8-bit selector. Identifies the type of header 206 immediately following the IPv6 metadata 207 header. 209 Hdr Ext Len 8-bit unsigned integer. Length of the 210 IPv6 metadata header in octets. 212 Metadata Stack Variable-length field, of length such that the 213 complete IPv6 metadata header is an 214 integer multiple of 8 octets long. Contains 215 one or more type of path Service Metadata . 217 For each specific path service, i.e. SFC/IOAM, the corresponding 218 metadata is defined as shown in Figure 3. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Service Type | Length | Reserved | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 ~ ~ 226 | Service Metadata (variable) | 227 ~ ~ 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 3. Service Metadata 232 Service Type 8-bit identifier of the type of 233 Metadata. 235 Length 8-bit unsigned integer. Length of the 236 Service Metadata field, in octets. 238 Metadata Variable-length field. Service-Type-specific data. 240 3. Processing Procedures for Handling IPv6 Metadata Header 242 With the introduction of the IPv6 Metadata Header, the processing of 243 the IPv6 Authentication Header (AH), Encapsulating Security Payload 244 header (ESP), and Fragment header (FH) need to be specified. 246 The processing of the IPv6 AH when the SRH is present in the same 247 packet is described in[I-D.herbert-ipv6-srh-ah]. The processing 248 procedures also need to be specified when the SRH is present in the 249 case of SRv6. 251 3.1. Processing of IPv6 Metadata Header 253 As specified in [RFC8200], when more than one extension header is 254 used in the same packet, it is recommended that those headers appear 255 in the following order: 257 IPv6 header 258 Hop-by-Hop Options header 259 Destination Options header 260 Routing header 261 Option 1----> 262 Fragment header 263 Authentication header 264 Encapsulating Security Payload header 265 Destination Options header 266 Option 2----> 267 Upper-Layer header 269 In the incremental tracing mode of IOAM, as the number of nodes 270 traversed by the IPv6 packets increases, the recorded IOAM 271 information will increase accordingly, which will increase the length 272 of the Metadata field. 274 If the IPv6 MH is placed before RH (SRH for SRv6), it will cause 275 increasing difficulties in reading the following SRH and thereby 276 reduce the forwarding performance of the data plane greatly. 277 Therefore, two options in the IPv6 extension headers are recommended 278 for inserting the IPv6 MH. The different locations for inserting the 279 IPv6 MH will also impact the processing of the AH, ESP, and FH, which 280 will be discussed in the following section. 282 Option 1: The IPv6 Metadata Header is inserted after the RH but 283 before FH. 285 Option 2: The IPv6 Metadata Header is placed as the last IPv6 286 extension header, i.e. after the second Destination Options header 287 but before the Upper-Layer header. 289 3.2. Interactions between IPv6 Metadata Header and Existing IPv6 290 Extension Headers 292 When the IPv6 Metadata is presented, the processing of AH, ESP, and 293 FH need to be specified. 295 3.2.1. Interactions between IPv6 Metadata Header and Authentication 296 Header 298 AH [RFC4302] is used to authenticate the preceding IPv6 header and 299 extension headers in a packet. Authentication is performed by 300 computing an Integrity Check Value (ICV) over the covered headers and 301 comparing the computed value to that contained in the ICV field of 302 the AH header. Both the sender and receiver (the final destination 303 in the case that a routing header is present) MUST independently and 304 deterministically perform the same computation over the same data. 306 When the IPv6 Metadata Header is presented, the processing of AH 307 needs to be specified. As specified in [RFC4302], AH may be employed 308 in two ways: transport mode or tunnel mode. See the Security 309 Architecture document [RFC4301] for a description of when each should 310 be used. 312 3.2.1.1. Transport Mode Processing 314 In transport mode, AH is inserted after the IP header and before a 315 next layer protocol (e.g., TCP, UDP, ICMP, etc.) or before any other 316 IPsec headers that have already been inserted. 318 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 319 should appear after hop-by-hop, routing, and fragmentation extension 320 headers. The destination options extension header(s) could appear 321 before or after or both before and after the AH header depending on 322 the semantics desired. 324 Since the IPv6 MH will be modified during transit (i.e. it is 325 mutable) and its value at the (IPsec) receiver is not predictable, 326 the value of the field is set to zero for purposes of the AH ICV 327 computation according to [RFC4302]. 329 When the IPv6 MH is introduced, the following diagram illustrates the 330 positioning of the IPv6 Metadata Header as well as the SRH in the AH 331 transport mode. 333 ------------------------------------------------------------ 334 | |hop-by-hop, dest*, | | dest | | | 335 |orig IP hdr |routing(SRH),MH,FH | AH | opt* | TCP | Data | 336 ------------------------------------------------------------ 337 |<--- mutable field processing -->|<-- immutable fields -->| 338 |<---- authenticated except for mutable fields ----------->| 340 * = if present, could be before AH, after AH, or both 342 3.2.1.2. Tunnel Mode Processing 344 In tunnel mode, the "inner" IP header carries the ultimate (IP) 345 source and destination addresses, while an "outer" IP header contains 346 the addresses of the IPsec "peers," e.g., addresses of security 347 gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 348 over IPv4 and IPv4 over IPv6. 350 In tunnel mode, AH protects the entire inner IP packet, including the 351 entire inner IP header. The position of AH in tunnel mode, relative 352 to the outer IP header, is the same as for AH in transport mode. The 353 following diagram illustrates the positioning of the IPv6 Metadata 354 Header as well as the SRH in the AH tunnel mode. 356 -------------------------------------------------------------- 357 | | ext hdrs*| | | ext hdrs*| | | 358 |new IP hdr*|(SRH, MH) | AH |orig IP hdr*|if present|TCP|Data| 359 -------------------------------------------------------------- 360 |<--- mutable field -->|<--------- immutable fields -------->| 361 | processing | 362 |<-- authenticated except for mutable fields in new IP hdr ->| 364 * = if present, construction of outer IP hdr/extensions and 365 modification of inner IP hdr/extensions is discussed in 366 the Security Architecture document. 368 3.2.2. Interactions between IPv6 Metadata Header and ESP header 370 When the IPv6 Metadata Header is presented, the processing of ESP 371 needs to be specified. As specified in [RFC4303], ESP may be 372 employed in two ways: transport mode or tunnel mode. 374 3.2.2.1. Transport Mode Processing 376 In transport mode, ESP is inserted after the IP header and before a 377 next layer protocol, e.g., TCP, UDP, ICMP, etc. 379 In the IPv6 context, ESP is viewed as an end-to-end payload, and 380 thus, as specified in [RFC4303], should appear after hop-by-hop, 381 routing, and fragmentation extension headers. Because ESP protects 382 only fields after the ESP header, it recommends that the destination 383 options header(s) is placed after the ESP header. 385 When the IPv6 MH is introduced, with option 2 in Section 3.1, the 386 IPv6 MH will be placed after the second DOH thereby encrypted, while 387 with option1, it will not be encrypted. 389 The following diagram illustrates the positioning of the IPv6 390 Metadata Header as well as the SRH in the ESP transport mode. 392 Option 1 393 ----------------------------------------------------------- 394 | orig |hop-by-hop,dest*, | |dest| | | ESP | ESP| 395 |IP hdr|routing(SRH),MH,FH |ESP|opt*|TCP|Data|Trailer| ICV| 396 ----------------------------------------------------------- 397 |<--- encryption ---->| 398 |<------ integrity ------>| 400 Option 2 401 --------------------------------------------------------------- 402 | orig |hop-by-hop,dest*,| |dest| | | | ESP | ESP| 403 |IP hdr|routing(SRH),FH. |ESP|opt*| MH | TCP|Data|Trailer| ICV| 404 --------------------------------------------------------------- 405 |<------ encryption ------->| 406 |<---------- integrity -------->| 408 * = if present, could be before ESP, after ESP, or both 410 3.2.2.2. Tunnel Mode Processing 412 In tunnel mode, the "inner" IP header carries the ultimate (IP) 413 source and destination addresses, while an "outer" IP header contains 414 the addresses of the IPsec "peers", e.g., addresses of security 415 gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 416 over IPv4 and IPv4 over IPv6. 418 In tunnel mode, ESP protects the entire inner IP packet, including 419 the entire inner IP header. The position of ESP in tunnel mode, 420 relative to the outer IP header, is the same as for ESP in transport 421 mode. The following diagram illustrates the positioning of the IPv6 422 Metadata Header as well as the SRH in the ESP tunnel mode. 424 ------------------------------------------------------------------------ 425 | new* | new ext hdrs | | orig*| orig ext hdrs | | | ESP | ESP| 426 |IP hdr| (SRH, MH)* |ESP|IP hdr| (SRH,MH) * |TCP|Data|Trailer| ICV| 427 ------------------------------------------------------------------------ 428 |<------------ encryption ------------->| 429 |<--------------- integrity --------------->| 431 * = if present, construction of outer IP hdr/extensions and 432 modification of inner IP hdr/extensions is discussed in 433 the Security Architecture document 435 3.2.3. Interactions between IPv6 Metadata Header and Fragment header 437 When the IPv6 Metadata is presented, the processing of FH needs to be 438 specified. 440 Note that in AH/ESP transport mode, for "bump-in-the-stack" or "bump- 441 in- the-wire" implementations, as defined in the Security 442 Architecture document, inbound and outbound IP fragments may require 443 an IPsec implementation to perform extra IP reassembly/fragmentation 444 in order to both conform to this specification and provide 445 transparent IPsec support. Special care is required to perform such 446 operations within these implementations when multiple interfaces are 447 in use. 449 4. IANA Considerations 451 This draft requests the following IPv6 Extension Header Type 452 assignments in the Assigned Internet Protocol Numbers registry. 454 https://www.iana.org/assignments/protocol-numbers/protocol- 455 numbers.xhtml 457 https://www.iana.org/assignments/ipv6-parameters/ipv6- 458 parameters.xhtml#extension-header 459 Protocol Number Description Reference 460 --------------------------------------------------------------------- 461 TBD_1 Enhanced Hop-by-Hop Options header [This draft] 462 TBD_2 IPv6 Metadata Header [This draft] 464 5. Security Considerations 466 As this document describes new extension headers for IPv6, these are 467 similar to the security considerations of [RFC8200]. 469 This document describes the encapsulation of IOAM and SFC metadata 470 fields in IPv6. Security considerations of the specific IOAM and SFC 471 metadata fields are described in [I-D.ietf-ippm-ioam-data] and 472 [RFC8300], respectively. 474 6. Normative References 476 [I-D.ali-6man-spring-srv6-oam] 477 Ali, Z., Filsfils, C., Kumar, N., Pignataro, C., Gandhi, 478 R., Brockners, F., Leddy, J., Matsushima, S., Raszuk, R., 479 daniel.voyer@bell.ca, d., Dawra, G., Peirens, B., Chen, 480 M., Li, C., and F. Iqbal, "Operations, Administration, and 481 Maintenance (OAM) in Segment Routing Networks with IPv6 482 Data plane (SRv6)", draft-ali-6man-spring-srv6-oam-01 483 (work in progress), March 2019. 485 [I-D.herbert-ipv6-srh-ah] 486 Herbert, T., "IPv6 Authentication Header with Segment 487 Routing Header Processing", draft-herbert-ipv6-srh-ah-00 488 (work in progress), May 2019. 490 [I-D.ietf-6man-segment-routing-header] 491 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 492 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 493 Routing Header (SRH)", draft-ietf-6man-segment-routing- 494 header-21 (work in progress), June 2019. 496 [I-D.ietf-ippm-ioam-data] 497 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 498 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 499 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 500 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 501 data-06 (work in progress), July 2019. 503 [I-D.ietf-spring-srv6-network-programming] 504 Filsfils, C., Camarillo, P., Leddy, J., 505 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 506 Network Programming", draft-ietf-spring-srv6-network- 507 programming-01 (work in progress), July 2019. 509 [I-D.ioametal-ippm-6man-ioam-ipv6-options] 510 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 511 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 512 Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, 513 "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam- 514 ipv6-options-02 (work in progress), March 2019. 516 [I-D.xuclad-spring-sr-service-programming] 517 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 518 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 519 Henderickx, W., and S. Salsano, "Service Programming with 520 Segment Routing", draft-xuclad-spring-sr-service- 521 programming-02 (work in progress), April 2019. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 529 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 530 December 2005, . 532 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 533 DOI 10.17487/RFC4302, December 2005, 534 . 536 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 537 RFC 4303, DOI 10.17487/RFC4303, December 2005, 538 . 540 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 541 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 542 RFC 6564, DOI 10.17487/RFC6564, April 2012, 543 . 545 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 546 (IPv6) Specification", STD 86, RFC 8200, 547 DOI 10.17487/RFC8200, July 2017, 548 . 550 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 551 "Network Service Header (NSH)", RFC 8300, 552 DOI 10.17487/RFC8300, January 2018, 553 . 555 Authors' Addresses 557 Zhenbin Li 558 Huawei Technologies 559 Huawei Bld., No.156 Beiqing Rd. 560 Beijing 100095 561 China 563 Email: lizhenbin@huawei.com 565 Shuping Peng 566 Huawei Technologies 567 Huawei Bld., No.156 Beiqing Rd. 568 Beijing 100095 569 China 571 Email: pengshuping@huawei.com