idnits 2.17.1 draft-ietf-v6ops-hbh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 October 2021) is 929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 400, but not defined == Unused Reference: 'RFC2711' is defined on line 575, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-10 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-11 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-06 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 S. Peng 3 Internet-Draft Z. Li 4 Intended status: Informational Huawei Technologies 5 Expires: 12 April 2022 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 G. Mishra 10 Verizon Inc. 11 9 October 2021 13 Operational Issues with Processing of the Hop-by-Hop Options Header 14 draft-ietf-v6ops-hbh-00 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 12 April 2022. 57 Copyright Notice 59 Copyright (c) 2021 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 Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Modern Router Architecture . . . . . . . . . . . . . . . . . 4 75 3. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 7 76 4. Common Implementations . . . . . . . . . . . . . . . . . . . 8 77 4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 9 78 4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 9 79 5. Operators' Typical Processing . . . . . . . . . . . . . . . . 9 80 6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. Migration Strategies . . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 12.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 Due to historical reasons, such as incapable ASICs, limited IPv6 94 deployments, and few service requirements, the most common Hop-by-Hop 95 Options header (HBH) processing implementation is that the node sends 96 the IPv6 packets with the Hop-by-Hop Options header to the control 97 plane of the node. The option type of each option carried within the 98 Hop-by-Hop Options header will not even be examined before the packet 99 is sent to the control plane. Very often, such processing behavior 100 is the default configuration or, even worse, is the only behavior of 101 the ipv6 implementation of the node. 103 Such default processing behavior of the Hop-by-Hop Options header 104 could result in various unpleasant effects such as a risk of Denial 105 of Service (DoS) attack on the router control plane and inconsistent 106 packet drops due to rate limiting on the interface between the router 107 control plane and forwarding plane, which will impact the normal end- 108 to-end IP forwarding of the network services. 110 This actually introduced a circular problem: 112 -> An implementation problem caused HBH to become a DoS vector. 114 -> Because HBH is a DoS vector, network operators deployed ACLs that 115 discard packets containing HBH. 117 -> Because network operators deployed ACLs that discard packets 118 containing HBH, network designers stopped defining new HBH Options. 120 -> Because network designers stopped defining new HBH Options, the 121 community was not motivated to fix the implementation problem that 122 cause HBH to become a DoS vector. 124 Driven by the wide deployments of IPv6 and ever-emerging new 125 services, the Hop-by-Hop Options Header is taken as a valuable 126 container for carrying the information to facilitate these new 127 services. 129 The purpose of this work is to 131 * Break the endless cycle that resulted in HBH to become a DOS 132 vector. 134 * Enable the HBH options header to be utilized in a safe and secure 135 way without impacting the management plane. 137 * Ease the deployments of the new HBH based network services in a 138 multi-vendor scenario that can now be deployed without operational 139 impact. 141 In this draft, the reasons why the HBH is rarely used within networks 142 will be documented and a proper list of requirements aiming to allow 143 a better leverage of the HBH capability will be defined. 145 2. Modern Router Architecture 147 Modern router architecture design maintains a strict separation of 148 the router control plane and its forwarding plane [RFC6192], as shown 149 in Figure 1. Either the control plane or the forwarding plane is 150 composed of both software and hardware, but each plane is responsible 151 for different functions. In this draft, we focus on only the routers 152 following the architecture as shown in Figure 1 and those being 153 deployed in the network rather than those at home. 155 +----------------+ 156 | Router Control | 157 | Plane | 158 +------+-+-------+ 159 | | 160 Interface Z 161 | | 162 +------+-+-------+ 163 | Forwarding | 164 Interface X ==[ Plane ]== Interface Y 165 +----------------+ 167 Figure 1. Modern Router Architecture 169 The router control plane supports routing and management functions, 170 handling packets destined to the device as well as building and 171 sending packets originated locally on the device, and also drives the 172 programming of the forwarding plane. The router control plane is 173 generally realized in software on general-purpose processors, and its 174 hardware is usually not optimized for high-speed packet handling. 175 Because of the wide range of functionality, it is more susceptible to 176 security vulnerabilities and a more likely a target for a DoS attack. 178 The forwarding plane is typically responsible for receiving a packet 179 on an incoming interface, performing a lookup to identify the 180 packet's next hop and determine the outgoing interface towards the 181 destination, and forwarding the packet out through the appropriate 182 outgoing interface. Typically, forwarding plane functionality is 183 realized in high-performance Application Specific Integrated Circuits 184 (ASICs) or Network Processors (NPs) that are capable of handling very 185 high packet rates. 187 The router control plane interfaces with its forwarding plane through 188 the Interface Z, as shown in the Figure 1, and the forwarding plane 189 connects to other network devices via Interfaces such as X and Y. 190 Since the router control plane is vulnerable to the DoS attack, 191 usually a traffic filtering mechanism is implemented on Interface Z 192 in order to block unwanted traffic. In order to protect the router 193 control plane, a rate-limiting mechanism is always implemented on 194 this interface. However, such rate limiting mechanism will always 195 cause inconsistent packet drops, which will impact the normal IP 196 forwarding. 198 Semiconductor chip technology has advanced significantly in the last 199 decade, and as such the widely used network processing and forwarding 200 process can now not only forward packets at line speed, but also 201 easily support other feature processing such as QoS for DiffServ/ 202 MPLS, Access Control List (ACL), Firewall, and Deep Packet Inspection 203 (DPI). 205 A Network Processing Unit (NPU) is a non-ASIC based Integrated 206 Circuit (IC) that is programmable through software. It performs all 207 packet header operations between the physical layer interface and the 208 switching fabric such as packet parsing and forwarding, modification, 209 and forwarding. Many equipment vendors implement these functions in 210 fixed function ASICs rather than using "off-the-shelf" NPUs, because 211 of proprietary algorithms. 213 Classification Co-processor is a specialized processor that can be 214 used to lighten the processing load on an NPU by handling the parsing 215 and classification of incoming packets such as IPv6 extended header 216 HBH options processing. This advancement enables network processors 217 to do the general process to handle simple control messages for 218 traffic management, such as signaling for hardware programming, 219 congestion state report, OAM, etc. Industry trend is for intelligent 220 multi-core CPU hardware using modern NPUs for forwarding packets at 221 line rate while still being able to perform other complex tasks such 222 as HBH forwarding options processing without having to punt to the 223 control plane. 225 Many of the packet-processing devices employed in modern switch and 226 router designs are fixed-function ASICs to handle proprietary 227 functions. While these devices can be very efficient for the set of 228 functions they are designed for, they can be very inflexible. There 229 is a tradeoff of price, performance and flexibility when vendors make 230 a choice to use a fixed function ASIC as opposed to NPU. Due to the 231 inflexibility of the fixed function ASIC, tasks that require 232 additional processing such as IPv6 HBH header processing must be 233 punted to the control plane. This problem is still a challenge today 234 and is the reason why operators to protect against control plane DOS 235 attack vector must drop or ignore HBH options. As industry shifts to 236 Merchant Silicon based NPU evolution from fixed function ASIC, the 237 gap will continue to close increasing the viability ubiquitous HBH 238 use cases due to now processing in the forwarding plane. 240 Most modern routers maintain a strict separation between forwarding 241 plane and control plane hardware. Forwarding plane bandwidth and 242 resources are plentiful, while control plane bandwidth and resources 243 are constrained. In order to protect scarce control plane resources, 244 routers enforce policies that restrict access from the forwarding 245 plane to the control plane. Effective policies address packets 246 containing the HBH Options Extension header, because HBH control 247 options require access from the forwarding plane to the control 248 plane. Many network operators perceive HBH Options to be a breach of 249 the separation between the forwarding and control planes. In this 250 case HBH control options would be required to be punted to control 251 plane by fixed function ASICs as well as NPUs. 253 The maximum length of an HBH Options header is 2,048 bytes. A source 254 node can encode hundreds of options in 2,048 bytes 255 [I-D.herbert-6man-eh-limits]. With today's technology it would be 256 cost prohibitive to be able to process hundreds of options with 257 either NPU or proprietary fixed function ASIC. 259 While [RFC2460] required that all nodes must examine and process the 260 Hop-by-Hop Options header, it is now expected that nodes along a 261 packet's delivery path only examine and process the Hop-by-Hop 262 Options header if explicitly configured to do so [RFC8200]. This can 263 be beneficial in cases where transit nodes are legacy hardware and 264 the destination endpoint PE is newer NPU based hardware that can 265 process HBH in the forwarding plane. 267 IPv6 Extended Header limitations that need to be addressed to make 268 HBH processing more efficient and viable in the forwarding plane: 270 [RFC8504] defines the IPv6 node requirements and how to protect a 271 node from excessive header chain and excessive header options with 272 various limitations that can be defined on a node. [RFC8883] defines 273 ICMPv6 Errors for discarding packets due to processing limits. Per 274 [RFC8200] HBH options must be processed serially. However, an 275 implementation of options processing can be made to be done with more 276 parallelism in serial processing grouping of similar options to be 277 processed in parallel. 279 The IPv6 standard does not currently limit the header chain length or 280 number of options that can be encoded. 282 Each Option is encoded in a TLV and so processing of a long list of 283 TLVs is expensive. Zero data length encoded options TLVs are a valid 284 option. A DOS vector could be easily generated by encoding 1000 HBH 285 options (Zero data length) in a standard 1500 MTU packet. So now 286 imagine if you have a Christmas tree long header chain to parse each 287 with many options. 289 3. Specification of RFC 8200 291 [RFC8200] defines several IPv6 extension header types, including the 292 Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- 293 by-Hop (HBH) Options header is used to carry optional information 294 that will be examined and processed by every node along a packet's 295 delivery path, and it is identified by a Next Header value of zero in 296 the IPv6 header. 298 The Hop-by-Hop (HBH) Options header contains the following fields: 300 -- Next Header: 8-bit selector, identifies the type of header 301 immediately following the Hop-by-Hop Options header. 303 -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 304 Options header in 8-octet units, not including the first 8 octets. 306 -- Options: Variable-length field, of length such that the complete 307 Hop-by-Hop Options header is an integer multiple of 8 octets long. 309 The Hop-by-Hop (HBH) Options header carries a variable number of 310 "options" that are encoded in the format of type-length-value (TLV). 312 The highest-order two bits (i.e., the ACT bits) of the Option Type 313 specify the action that must be taken if the processing IPv6 node 314 does not recognize the Option Type. The third-highest-order bit 315 (i.e., the CHG bit) of the Option Type specifies whether or not the 316 Option Data of that option can change en route to the packet's final 317 destination. 319 While [RFC2460] required that all nodes must examine and process the 320 Hop-by-Hop Options header, it is now expected that nodes along a 321 packet's delivery path only examine and process the Hop-by-Hop 322 Options header if explicitly configured to do so [RFC8200]. It means 323 that the HBH processing behavior in a node depends on its 324 configuration. 326 However, in the current [RFC8200], there is no explicit specification 327 of the possible configurations. Therefore, the nodes may be 328 configured to ignore the Hop-by-Hop Options header, drop packets 329 containing a Hop-by-Hop Options header, or assign packets containing 330 a Hop-by-Hop Options header to the control plane [RFC8200]. Because 331 of these likely uncertain processing behaviors, new hop-by-hop 332 options are not recommended. 334 4. Common Implementations 336 In the current common implementations, once an IPv6 packet, with its 337 Next Header field set to 0, arrives at a node, it will be directly 338 sent to the control plane of the node. With such implementations, 339 the value of the Next Header field in the IPv6 header is the only 340 trigger for the default processing behavior. The option type of each 341 option carried within the Hop-by-Hop Options header will not even be 342 examined before the packet is sent to the control plane. 344 Very often, such processing behavior is the default configuration on 345 the node, which is embedded in the implementation and cannot be 346 changed or reconfigured. 348 Another critical component of IPv6 HBH processing, in some cases 349 overlooked, is the operator core network which can be designed to use 350 the global Internet routing table for internet traffic and in other 351 cases use an overlay MPLS VPN to carry Internet traffic. 353 In the global Internet routing table scenario where only an underlay 354 global routing table exists, and no VPN overlay carrying customer 355 Internet traffic, the IPv6 HBH options can be used as a DOS attack 356 vector for both the operator nodes, adjacent inter-as peer nodes as 357 well as customer nodes along a path. 359 In a case where the Internet routing table is carried in a MPLS VPN 360 overlay payload, the HBH options header does not impact the operator 361 underlay framework and only impacts the VPN overlay payload and thus 362 the operator underlay topmost label global table routing FEC LSP 363 instantiation is not impacted as the operator underlay is within the 364 operators closed domain. 366 However, HBH options DOS attack vector in the VPN overlay can still 367 impact the customer CE destination end nodes as well as other 368 adjacent inter-as operators that only use underlay global Internet 369 routing table. In an operator closed domain where MPLS VPN overlay 370 is utilized to carry internet traffic, the operator has full control 371 of the underlay and IPv6 Extended header chain length as well as the 372 number of HBH options encoded. 374 In the global routing table scenario for Internet traffic there is no 375 way to control the IPv6 Extended header chain length as well as the 376 number of HBH options encoded. 378 4.1. Historical Reasons 380 When IPv6 was first implemented on high-speed routers, HBH options 381 were not yet well-understood and ASICs were not as capable as they 382 are today. So, early IPv6 implementations dispatched all packets 383 that contain HBH options to their control plane. 385 4.2. Consequences 387 Such implementation introduces a risk of a DoS attack on the control 388 plane of the node, and a large flow of IPv6 packets could congest the 389 control plane, causing other critical functions (including routing 390 and network management) that are executed on the control plane to 391 fail. Rate limiting mechanisms will cause inconsistent packet drops 392 and impact the normal end-to-end IP forwarding of the network 393 services. 395 5. Operators' Typical Processing 397 To mitigate this DoS vulnerability, many operators deployed Access 398 Control Lists (ACLs) that discard all packets containing HBH Options. 400 [RFC6564] shows the Reports from the field indicating that some IP 401 routers deployed within the global Internet are configured either to 402 ignore or to drop packets having a hop-by-hop header. As stated in 403 [RFC7872], many network operators perceive HBH Options to be a breach 404 of the separation between the forwarding and control planes. 405 Therefore, several network operators configured their nodes so as to 406 discard all packets containing the HBH Options Extension Header, 407 while others configured nodes to forward the packet but to ignore the 408 HBH Options. [RFC7045] also states that hop-by-hop options are not 409 handled by many high-speed routers or are processed only on a control 410 plane. 412 Due to such behaviors observed and described in these specifications, 413 new hop-by-hop options are not recommended in [RFC8200] hence the 414 usability of HBH options is severely limited. 416 6. New Services 418 As IPv6 is being rapidly and widely deployed worldwide, more and more 419 applications and network services are migrating to or directly 420 adopting IPv6. More and more new services that require HBH are 421 emerging and the HBH Options header is going to be utilized by the 422 new services in various scenarios. 424 In-situ OAM (IOAM) with IPv6 encapsulation 425 [I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in 426 IPv6 is used to enhance diagnostics of IPv6 networks and complements 427 other mechanisms, such as the IPv6 Performance and Diagnostic Metrics 428 Destination Option described in [RFC8250]. The IOAM data fields are 429 encapsulated in "option data" fields of the Hop-by-Hop Options 430 header. 432 Alternate Marking Method can be used as the passive performance 433 measurement tool in an IPv6 domain. The AltMark Option is defined as 434 a new IPv6 extension header option to encode alternate marking 435 technique and Hop-by-Hop Options Header is considered 436 [I-D.ietf-6man-ipv6-alt-mark]. 438 The Minimum Path MTU Hop-by-Hop Option is defined in 439 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 440 forward path between a source host to a destination host. This Hop- 441 by-Hop option is intended to be used in environments like Data 442 Centers and on paths between Data Centers as well as other 443 environments including the general Internet. It provides a useful 444 tool for allowing to better take advantage of paths able to support a 445 large Path MTU. 447 As more services start utilizing the HBH Options header, more packets 448 containing HBH Options are going to be injected into the networks. 449 According to the current common configuration in most network 450 deployments, all the packets of the new services are going to be sent 451 to the control plane of the nodes, with the possible consequence of 452 causing a DoS on the control plane. The packets will be dropped and 453 the normal IP forwarding may be severely impacted. The deployment of 454 new network services involving multi-vendor interoperability will 455 become impossible. 457 7. Requirements 458 * The HBH options header SHOULD NOT become a possible DDoS Vector. 459 Therefore, the control plane MUST be preserved from unwanted 460 incoming traffic due to HBH header present in the packet. 462 * HBH options SHOULD be designed in a manner so that they don't 463 reduce the probability of packet delivery. 465 * HBH processing MUST be efficient. That is, it MUST be possible to 466 produce implementations that perform well at a reasonable cost 467 without endanger the security of the router. 469 * The Router Alert Option MUST NOT impact the processing of other 470 HBH options that should be processed more quickly. 472 * HBH Options MAY influence how a packet is forwarded. However, 473 with the exception of the Router Alert Option, an HBH Option MUST 474 NOT cause control plane state to be created, modified or destroyed 475 on the processing node. As per [RFC6398], protocol developers 476 SHOULD avoid future use of the Router Alert Option. 478 * More requirements are to be added. 480 8. Migration Strategies 482 In order to make the HBH options header usable and facilitate the 483 ever-emerging new services to be deployed across multiple vendors' 484 devices, the new HBH header scheme, SHOULD allow a smooth migration 485 from old to new behavior without disruption time. Also, co-existence 486 between old and news scheme MUST be possible. 488 9. Security Considerations 490 The same as the Security Considerations apply as in [RFC8200] for the 491 part related with the HBH Options header. 493 10. IANA Considerations 495 This document does not include an IANA request. 497 11. Acknowledgements 499 The authors would like to acknowledge Ron Bonica, Fred Baker, Bob 500 Hinden, Stefano Previdi, and Donald Eastlake for their valuable 501 review and comments. 503 12. References 505 12.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 513 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 514 December 1998, . 516 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 517 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 518 March 2011, . 520 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 521 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 522 2011, . 524 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 525 of IPv6 Extension Headers", RFC 7045, 526 DOI 10.17487/RFC7045, December 2013, 527 . 529 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 530 "Observations on the Dropping of Packets with IPv6 531 Extension Headers in the Real World", RFC 7872, 532 DOI 10.17487/RFC7872, June 2016, 533 . 535 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 536 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 537 May 2017, . 539 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 540 (IPv6) Specification", STD 86, RFC 8200, 541 DOI 10.17487/RFC8200, July 2017, 542 . 544 12.2. Informative References 546 [I-D.herbert-6man-eh-limits] 547 Herbert, T., "Limits on Sending and Processing IPv6 548 Extension Headers", Work in Progress, Internet-Draft, 549 draft-herbert-6man-eh-limits-00, 22 June 2021, 550 . 553 [I-D.ietf-6man-ipv6-alt-mark] 554 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 555 Pang, "IPv6 Application of the Alternate Marking Method", 556 Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- 557 alt-mark-10, 14 September 2021, 558 . 561 [I-D.ietf-6man-mtu-option] 562 Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU 563 Hop-by-Hop Option", Work in Progress, Internet-Draft, 564 draft-ietf-6man-mtu-option-11, 30 September 2021, 565 . 568 [I-D.ietf-ippm-ioam-ipv6-options] 569 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 570 Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- 571 ipv6-options-06, 31 July 2021, 572 . 575 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 576 RFC 2711, DOI 10.17487/RFC2711, October 1999, 577 . 579 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 580 Performance and Diagnostic Metrics (PDM) Destination 581 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 582 . 584 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 585 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 586 January 2019, . 588 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 589 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 590 September 2020, . 592 Authors' Addresses 594 Shuping Peng 595 Huawei Technologies 596 Beijing 597 China 599 Email: pengshuping@huawei.com 600 Zhenbin Li 601 Huawei Technologies 602 Beijing 603 China 605 Email: lizhenbin@huawei.com 607 Chongfeng Xie 608 China Telecom 609 China 611 Email: xiechf@chinatelecom.cn 613 Zhuangzhuang Qin 614 China Unicom 615 Beijing 616 China 618 Email: qinzhuangzhuang@chinaunicom.cn 620 Gyan Mishra 621 Verizon Inc. 622 United States of America 624 Email: gyan.s.mishra@verizon.com