idnits 2.17.00 (12 Aug 2021) /tmp/idnits65372/draft-ietf-v6ops-hbh-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (18 April 2022) is 26 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 405, but not defined == Unused Reference: 'RFC2711' is defined on line 597, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-6man-ipv6-alt-mark-13 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-14 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Peng 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: 20 October 2022 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 G. Mishra 10 Verizon Inc. 11 18 April 2022 13 Operational Issues with Processing of the Hop-by-Hop Options Header 14 draft-ietf-v6ops-hbh-01 16 Abstract 18 This document describes the processing of the Hop-by-Hop Options 19 Header (HBH) in today's routers in the aspects of standards 20 specification, common implementations, and default operations. This 21 document outlines the reasons why the Hop-by-Hop Options Header is 22 rarely utilized in current networks. In addition, this document 23 describes how the HBH could be used as a powerful mechanism allowing 24 deployment and operations of new services requiring a more optimized 25 way to leverage network resources of an infrastructure. The Hop-by- 26 Hop Options Header is taken into consideration by several network 27 operators as a valuable container for carrying the information 28 facilitating the introduction of new services. The purpose of this 29 draft is to document the reasons why the HBH is rarely used within 30 networks and to define a proper list of requirements aiming to allow 31 a better leverage of the HBH capability. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119] [RFC8174] 38 when, and only when, they appear in all capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 20 October 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Modern Router Architecture . . . . . . . . . . . . . . . . . 4 76 4. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 7 77 5. Common Implementations . . . . . . . . . . . . . . . . . . . 8 78 5.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 9 79 5.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Typical Processing . . . . . . . . . . . . . . . . . . . . . 9 81 7. New Services . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. Migration Strategies . . . . . . . . . . . . . . . . . . . . 11 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 13.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 Due to historical reasons, such as incapable ASICs, limited IPv6 95 deployments, and few service requirements, the most common Hop-by-Hop 96 Options header (HBH) processing implementation is that the node sends 97 the IPv6 packets with the Hop-by-Hop Options header to the control 98 plane of the node. The option type of each option carried within the 99 Hop-by-Hop Options header will not even be examined before the packet 100 is sent to the control plane. Very often, such processing behavior 101 is the default configuration or, even worse, is the only behavior of 102 the ipv6 implementation of the node. 104 Such default processing behavior of the Hop-by-Hop Options header 105 could result in various unpleasant effects such as a risk of Denial 106 of Service (DoS) attack on the router control plane and inconsistent 107 packet drops due to rate limiting on the interface between the router 108 control plane and forwarding plane, which will impact the normal end- 109 to-end IP forwarding of the network services. 111 This actually introduced a circular problem: 113 -> An implementation problem caused HBH to become a DoS vector. 115 -> Because HBH is a DoS vector, network operators deployed ACLs that 116 discard packets containing HBH. 118 -> Because network operators deployed ACLs that discard packets 119 containing HBH, network designers stopped defining new HBH Options. 121 -> Because network designers stopped defining new HBH Options, the 122 community was not motivated to fix the implementation problem that 123 cause HBH to become a DoS vector. 125 Driven by the wide deployments of IPv6 and ever-emerging new 126 services, the Hop-by-Hop Options Header is taken as a valuable 127 container for carrying the information to facilitate these new 128 services. 130 The purpose of this work is to 132 * Break the endless cycle that resulted in HBH to become a DOS 133 vector. 135 * Enable the HBH options header to be utilized in a safe and secure 136 way without impacting the management plane. 138 * Ease the deployments of the new HBH based network services in a 139 multi-vendor scenario that can now be deployed without operational 140 impact. 142 In this draft, the reasons why the HBH is rarely used within networks 143 will be documented and a proper list of requirements aiming to allow 144 a better leverage of the HBH capability will be defined. 146 2. Terminology 148 The Forwarding Plane and Control Plane used in this draft can refer 149 to the same terminologies as defined in 150 [I-D.ietf-6man-hbh-processing], respectively. 152 3. Modern Router Architecture 154 Modern router architecture design maintains a strict separation of 155 the router control plane and its forwarding plane [RFC6192], as shown 156 in Figure 1. Either the control plane or the forwarding plane is 157 composed of both software and hardware, but each plane is responsible 158 for different functions. In this draft, we focus on only the routers 159 following the architecture as shown in Figure 1 and those being 160 deployed in the network rather than those at home. 162 +----------------+ 163 | Router Control | 164 | Plane | 165 +------+-+-------+ 166 | | 167 Interface Z 168 | | 169 +------+-+-------+ 170 | Forwarding | 171 Interface X ==[ Plane ]== Interface Y 172 +----------------+ 174 Figure 1. Modern Router Architecture 176 The router control plane supports routing and management functions, 177 handling packets destined to the device as well as building and 178 sending packets originated locally on the device, and also drives the 179 programming of the forwarding plane. The router control plane is 180 generally realized in software on general-purpose processors, and its 181 hardware is usually not optimized for high-speed packet handling. 182 Because of the wide range of functionality, it is more susceptible to 183 security vulnerabilities and a more likely a target for a DoS attack. 185 The forwarding plane is typically responsible for receiving a packet 186 on an incoming interface, performing a lookup to identify the 187 packet's next hop and determine the outgoing interface towards the 188 destination, and forwarding the packet out through the appropriate 189 outgoing interface. Typically, forwarding plane functionality is 190 realized in high-performance Application Specific Integrated Circuits 191 (ASICs) or Network Processors (NPs) that are capable of handling very 192 high packet rates. 194 The router control plane interfaces with its forwarding plane through 195 the Interface Z, as shown in the Figure 1, and the forwarding plane 196 connects to other network devices via Interfaces such as X and Y. 197 Since the router control plane is vulnerable to the DoS attack, 198 usually a traffic filtering mechanism is implemented on Interface Z 199 in order to block unwanted traffic. In order to protect the router 200 control plane, a rate-limiting mechanism is always implemented on 201 this interface. However, such rate limiting mechanism will always 202 cause inconsistent packet drops, which will impact the normal IP 203 forwarding. 205 Semiconductor chip technology has advanced significantly in the last 206 decade, and as such the widely used network processing and forwarding 207 process can now not only forward packets at line speed, but also 208 easily support other feature processing such as QoS for DiffServ/ 209 MPLS, Access Control List (ACL), Firewall, and Deep Packet Inspection 210 (DPI). 212 A Network Processing Unit (NPU) is a non-ASIC based Integrated 213 Circuit (IC) that is programmable through software. It performs all 214 packet header operations between the physical layer interface and the 215 switching fabric such as packet parsing and forwarding, modification, 216 and forwarding. Many equipment vendors implement these functions in 217 fixed function ASICs rather than using "off-the-shelf" NPUs, because 218 of proprietary algorithms. 220 Classification Co-processor is a specialized processor that can be 221 used to lighten the processing load on an NPU by handling the parsing 222 and classification of incoming packets such as IPv6 extended header 223 HBH options processing. This advancement enables network processors 224 to do the general process to handle simple control messages for 225 traffic management, such as signaling for hardware programming, 226 congestion state report, OAM, etc. Industry trend is for intelligent 227 multi-core CPU hardware using modern NPUs for forwarding packets at 228 line rate while still being able to perform other complex tasks such 229 as HBH forwarding options processing without having to punt to the 230 control plane. 232 Many of the packet-processing devices employed in modern switch and 233 router designs are fixed-function ASICs to handle proprietary 234 functions. While these devices can be very efficient for the set of 235 functions they are designed for, they can be very inflexible. There 236 is a tradeoff of price, performance and flexibility when vendors make 237 a choice to use a fixed function ASIC as opposed to NPU. Due to the 238 inflexibility of the fixed function ASIC, tasks that require 239 additional processing such as IPv6 HBH header processing must be 240 punted to the control plane. This problem is still a challenge today 241 and is the reason why operators to protect against control plane DOS 242 attack vector must drop or ignore HBH options. As industry shifts to 243 Merchant Silicon based NPU evolution from fixed function ASIC, the 244 gap will continue to close increasing the viability ubiquitous HBH 245 use cases due to now processing in the forwarding plane. 247 Most modern routers maintain a strict separation between forwarding 248 plane and control plane hardware. Forwarding plane bandwidth and 249 resources are plentiful, while control plane bandwidth and resources 250 are constrained. In order to protect scarce control plane resources, 251 routers enforce policies that restrict access from the forwarding 252 plane to the control plane. Effective policies address packets 253 containing the HBH Options Extension header, because HBH control 254 options require access from the forwarding plane to the control 255 plane. Many network operators perceive HBH Options to be a breach of 256 the separation between the forwarding and control planes. In this 257 case HBH control options would be required to be punted to control 258 plane by fixed function ASICs as well as NPUs. 260 The maximum length of an HBH Options header is 2,048 bytes. A source 261 node can encode hundreds of options in 2,048 bytes 262 [I-D.herbert-6man-eh-limits]. With today's technology it would be 263 cost prohibitive to be able to process hundreds of options with 264 either NPU or proprietary fixed function ASIC. 266 As per [RFC8200], it is now expected that nodes along a packet's 267 delivery path only examine and process the Hop-by-Hop Options header 268 if explicitly configured to do so. This can be beneficial in cases 269 where transit nodes are legacy hardware and the destination endpoint 270 PE is newer NPU based hardware that can process HBH in the forwarding 271 plane. 273 IPv6 Extended Header limitations that need to be addressed to make 274 HBH processing more efficient and viable in the forwarding plane: 276 [RFC8504] defines the IPv6 node requirements and how to protect a 277 node from excessive header chain and excessive header options with 278 various limitations that can be defined on a node. [RFC8883] defines 279 ICMPv6 Errors for discarding packets due to processing limits. Per 281 [RFC8200] HBH options must be processed serially. However, an 282 implementation of options processing can be made to be done with more 283 parallelism in serial processing grouping of similar options to be 284 processed in parallel. 286 The IPv6 standard does not currently limit the header chain length or 287 number of options that can be encoded. 289 Each Option is encoded in a TLV and so processing of a long list of 290 TLVs is expensive. Zero data length encoded options TLVs are a valid 291 option. A DOS vector could be easily generated by encoding 1000 HBH 292 options (Zero data length) in a standard 1500 MTU packet. So now 293 imagine if you have a Christmas tree long header chain to parse each 294 with many options. 296 4. Specification of RFC 8200 298 [RFC8200] defines several IPv6 extension header types, including the 299 Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- 300 by-Hop (HBH) Options header is used to carry optional information 301 that will be examined and processed by every node along a packet's 302 delivery path, and it is identified by a Next Header value of zero in 303 the IPv6 header. 305 The Hop-by-Hop (HBH) Options header contains the following fields: 307 -- Next Header: 8-bit selector, identifies the type of header 308 immediately following the Hop-by-Hop Options header. 310 -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 311 Options header in 8-octet units, not including the first 8 octets. 313 -- Options: Variable-length field, of length such that the complete 314 Hop-by-Hop Options header is an integer multiple of 8 octets long. 316 The Hop-by-Hop (HBH) Options header carries a variable number of 317 "options" that are encoded in the format of type-length-value (TLV). 319 The highest-order two bits (i.e., the ACT bits) of the Option Type 320 specify the action that must be taken if the processing IPv6 node 321 does not recognize the Option Type. The third-highest-order bit 322 (i.e., the CHG bit) of the Option Type specifies whether or not the 323 Option Data of that option can change en route to the packet's final 324 destination. 326 As per [RFC8200], it is now expected that nodes along a packet's 327 delivery path only examine and process the Hop-by-Hop Options header 328 if explicitly configured to do so. It means that the HBH processing 329 behavior in a node depends on its configuration. 331 However, in the current [RFC8200], there is no explicit specification 332 of the possible configurations. Therefore, the nodes may be 333 configured to ignore the Hop-by-Hop Options header, drop packets 334 containing a Hop-by-Hop Options header, or assign packets containing 335 a Hop-by-Hop Options header to the control plane [RFC8200]. Because 336 of these likely uncertain processing behaviors, new hop-by-hop 337 options are not recommended. 339 5. Common Implementations 341 In the current common implementations, once an IPv6 packet, with its 342 Next Header field set to 0, arrives at a node, it will be directly 343 sent to the control plane of the node. With such implementations, 344 the value of the Next Header field in the IPv6 header is the only 345 trigger for the default processing behavior. The option type of each 346 option carried within the Hop-by-Hop Options header will not even be 347 examined before the packet is sent to the control plane. 349 Very often, such processing behavior is the default configuration on 350 the node, which is embedded in the implementation and cannot be 351 changed or reconfigured. 353 Another critical component of IPv6 HBH processing, in some cases 354 overlooked, is the operator core network which can be designed to use 355 the global Internet routing table for internet traffic and in other 356 cases use an overlay MPLS VPN to carry Internet traffic. 358 In the global Internet routing table scenario where only an underlay 359 global routing table exists, and no VPN overlay carrying customer 360 Internet traffic, the IPv6 HBH options can be used as a DOS attack 361 vector for both the operator nodes, adjacent inter-as peer nodes as 362 well as customer nodes along a path. 364 In a case where the Internet routing table is carried in a MPLS VPN 365 overlay payload, the HBH options header does not impact the operator 366 underlay framework and only impacts the VPN overlay payload and thus 367 the operator underlay topmost label global table routing FEC LSP 368 instantiation is not impacted as the operator underlay is within the 369 operators closed domain. 371 However, HBH options DOS attack vector in the VPN overlay can still 372 impact the customer CE destination end nodes as well as other 373 adjacent inter-as operators that only use underlay global Internet 374 routing table. In an operator closed domain where MPLS VPN overlay 375 is utilized to carry internet traffic, the operator has full control 376 of the underlay and IPv6 Extended header chain length as well as the 377 number of HBH options encoded. 379 In the global routing table scenario for Internet traffic there is no 380 way to control the IPv6 Extended header chain length as well as the 381 number of HBH options encoded. 383 5.1. Historical Reasons 385 When IPv6 was first implemented on high-speed routers, HBH options 386 were not yet well-understood and ASICs were not as capable as they 387 are today. So, early IPv6 implementations dispatched all packets 388 that contain HBH options to their control plane. 390 5.2. Consequences 392 Such implementation introduces a risk of a DoS attack on the control 393 plane of the node, and a large flow of IPv6 packets could congest the 394 control plane, causing other critical functions (including routing 395 and network management) that are executed on the control plane to 396 fail. Rate limiting mechanisms will cause inconsistent packet drops 397 and impact the normal end-to-end IP forwarding of the network 398 services. 400 6. Typical Processing 402 To mitigate this DoS vulnerability, many operators deployed Access 403 Control Lists (ACLs) that discard all packets containing HBH Options. 405 [RFC6564] shows the Reports from the field indicating that some IP 406 routers deployed within the global Internet are configured either to 407 ignore or to drop packets having a hop-by-hop header. As stated in 408 [RFC7872], many network operators perceive HBH Options to be a breach 409 of the separation between the forwarding and control planes. 410 Therefore, several network operators configured their nodes so as to 411 discard all packets containing the HBH Options Extension Header, 412 while others configured nodes to forward the packet but to ignore the 413 HBH Options. [RFC7045] also states that hop-by-hop options are not 414 handled by many high-speed routers or are processed only on a control 415 plane. [I-D.vyncke-v6ops-james] shows that the HBH options header 416 cannot reliably traverse the global Internet; only small headers with 417 'skipable' options have some chances. 419 Due to such behaviors observed and described in these specifications, 420 new hop-by-hop options are not recommended in [RFC8200] hence the 421 usability of HBH options is severely limited. 423 Besides service providers' networks, other sectors such as industrial 424 IoT networks are slowly replacing a dozen of semi-proprietary 425 protocols in industrial automation into IP. The proper processing of 426 the HBH options header is also required. 428 7. New Services 430 As IPv6 is being rapidly and widely deployed worldwide, more and more 431 applications and network services are migrating to or directly 432 adopting IPv6. More and more new services that require HBH are 433 emerging and the HBH Options header is going to be utilized by the 434 new services in various scenarios. 436 In-situ OAM (IOAM) with IPv6 encapsulation 437 [I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in 438 IPv6 is used to enhance diagnostics of IPv6 networks and complements 439 other mechanisms, such as the IPv6 Performance and Diagnostic Metrics 440 Destination Option described in [RFC8250]. The IOAM data fields are 441 encapsulated in "option data" fields of the Hop-by-Hop Options 442 header. 444 Alternate Marking Method can be used as the passive performance 445 measurement tool in an IPv6 domain. The AltMark Option is defined as 446 a new IPv6 extension header option to encode alternate marking 447 technique and Hop-by-Hop Options Header is considered 448 [I-D.ietf-6man-ipv6-alt-mark]. 450 The Minimum Path MTU Hop-by-Hop Option is defined in 451 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 452 forward path between a source host to a destination host. This Hop- 453 by-Hop option is intended to be used in environments like Data 454 Centers and on paths between Data Centers as well as other 455 environments including the general Internet. It provides a useful 456 tool for allowing to better take advantage of paths able to support a 457 large Path MTU. 459 As more services start utilizing the HBH Options header, more packets 460 containing HBH Options are going to be injected into the networks. 461 According to the current common configuration in most network 462 deployments, all the packets of the new services are going to be sent 463 to the control plane of the nodes, with the possible consequence of 464 causing a DoS on the control plane. The packets will be dropped and 465 the normal IP forwarding may be severely impacted. The deployment of 466 new network services involving multi-vendor interoperability will 467 become impossible. 469 8. Requirements 470 * The HBH options header SHOULD NOT become a possible DDoS Vector. 471 Therefore, the control plane MUST be preserved from unwanted 472 incoming traffic due to HBH header present in the packet. 474 * HBH options SHOULD be designed in a manner so that they don't 475 reduce the probability of packet delivery. 477 * HBH processing MUST be efficient. That is, it MUST be possible to 478 produce implementations that perform well at a reasonable cost 479 without endanger the security of the router. 481 * The Router Alert Option MUST NOT impact the processing of other 482 HBH options that should be processed more quickly. 484 * HBH Options MAY influence how a packet is forwarded. However, 485 with the exception of the Router Alert Option, an HBH Option MUST 486 NOT cause control plane state to be created, modified or destroyed 487 on the processing node. As per [RFC6398], protocol developers 488 SHOULD avoid future use of the Router Alert Option. 490 * More requirements are to be added. 492 9. Migration Strategies 494 In order to make the HBH options header usable and facilitate the 495 ever-emerging new services to be deployed across multiple vendors' 496 devices, the new HBH header scheme, SHOULD allow a smooth migration 497 from old to new behavior without disruption time. Also, co-existence 498 between old and news scheme MUST be possible. 500 10. Security Considerations 502 The same as the Security Considerations apply as in [RFC8200] for the 503 part related with the HBH Options header. 505 11. IANA Considerations 507 This document does not include an IANA request. 509 12. Acknowledgements 511 The authors would like to acknowledge Ron Bonica, Fred Baker, Bob 512 Hinden, Stefano Previdi, and Donald Eastlake for their valuable 513 review and comments. 515 13. References 517 13.1. Normative References 519 [I-D.ietf-6man-hbh-processing] 520 Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 521 Processing Procedures", Work in Progress, Internet-Draft, 522 draft-ietf-6man-hbh-processing-00, 29 January 2022, 523 . 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, 528 DOI 10.17487/RFC2119, March 1997, 529 . 531 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 532 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 533 March 2011, . 535 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 536 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 537 2011, . 539 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 540 of IPv6 Extension Headers", RFC 7045, 541 DOI 10.17487/RFC7045, December 2013, 542 . 544 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 545 "Observations on the Dropping of Packets with IPv6 546 Extension Headers in the Real World", RFC 7872, 547 DOI 10.17487/RFC7872, June 2016, 548 . 550 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 551 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 552 May 2017, . 554 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 555 (IPv6) Specification", STD 86, RFC 8200, 556 DOI 10.17487/RFC8200, July 2017, 557 . 559 13.2. Informative References 561 [I-D.herbert-6man-eh-limits] 562 Herbert, T., "Limits on Sending and Processing IPv6 563 Extension Headers", Work in Progress, Internet-Draft, 564 draft-herbert-6man-eh-limits-00, 22 June 2021, 565 . 568 [I-D.ietf-6man-ipv6-alt-mark] 569 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 570 Pang, "IPv6 Application of the Alternate Marking Method", 571 Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- 572 alt-mark-13, 31 March 2022, 573 . 576 [I-D.ietf-6man-mtu-option] 577 Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU 578 Hop-by-Hop Option", Work in Progress, Internet-Draft, 579 draft-ietf-6man-mtu-option-14, 15 April 2022, 580 . 583 [I-D.ietf-ippm-ioam-ipv6-options] 584 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 585 Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- 586 ipv6-options-07, 6 February 2022, 587 . 590 [I-D.vyncke-v6ops-james] 591 Vyncke, É., Léas, R., and J. Iurman, "Just Another 592 Measurement of Extension header Survivability (JAMES)", 593 Work in Progress, Internet-Draft, draft-vyncke-v6ops- 594 james-01, 19 March 2022, . 597 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 598 RFC 2711, DOI 10.17487/RFC2711, October 1999, 599 . 601 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 602 Performance and Diagnostic Metrics (PDM) Destination 603 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 604 . 606 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 607 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 608 January 2019, . 610 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 611 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 612 September 2020, . 614 Authors' Addresses 615 Shuping Peng 616 Huawei Technologies 617 Beijing 618 China 619 Email: pengshuping@huawei.com 621 Zhenbin Li 622 Huawei Technologies 623 Beijing 624 China 625 Email: lizhenbin@huawei.com 627 Chongfeng Xie 628 China Telecom 629 China 630 Email: xiechf@chinatelecom.cn 632 Zhuangzhuang Qin 633 China Unicom 634 Beijing 635 China 636 Email: qinzhuangzhuang@chinaunicom.cn 638 Gyan Mishra 639 Verizon Inc. 640 United States of America 641 Email: gyan.s.mishra@verizon.com