idnits 2.17.1 draft-peng-v6ops-hbh-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 August 2021) is 970 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 388, but not defined == Unused Reference: 'RFC2711' is defined on line 589, 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-08 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-06 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-14 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-06 Summary: 1 error (**), 0 flaws (~~), 7 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: 24 February 2022 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 G. Mishra 10 Verizon Inc. 11 23 August 2021 13 Processing of the Hop-by-Hop Options Header 14 draft-peng-v6ops-hbh-06 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 processing 29 requirments of the HBH and the migration strategies are also 30 suggested. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [RFC2119] [RFC8174] 37 when, and only when, they appear in all capitals, as shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 24 February 2022. 56 Copyright Notice 58 Copyright (c) 2021 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Simplified BSD License text 67 as described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Modern Router Architecture . . . . . . . . . . . . . . . . . 4 74 3. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 7 75 4. Common Implementations . . . . . . . . . . . . . . . . . . . 8 76 4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 9 77 4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 9 78 5. Operators' Typical Processing . . . . . . . . . . . . . . . . 9 79 6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Migration Strategies . . . . . . . . . . . . . . . . . . . . 11 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 12.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 Due to historical reasons, such as incapable ASICs, limited IPv6 93 deployments, and few service requirements, the most common Hop-by-Hop 94 Options header (HBH) processing implementation is that the node sends 95 the IPv6 packets with the Hop-by-Hop Options header to the control 96 plane of the node. The option type of each option carried within the 97 Hop-by-Hop Options header will not even be examined before the packet 98 is sent to the control plane. Very often, such processing behavior 99 is the default configuration or, even worse, is the only behavior of 100 the ipv6 implementation of the node. 102 Such default processing behavior of the Hop-by-Hop Options header 103 could result in various unpleasant effects such as a risk of Denial 104 of Service (DoS) attack on the router control plane and inconsistent 105 packet drops due to rate limiting on the interface between the router 106 control plane and forwarding plane, which will impact the normal end- 107 to-end IP forwarding of the network services. 109 This actually introduced a circular problem: 111 -> An implementation problem caused HBH to become a DoS vector. 113 -> Because HBH is a DoS vector, network operators deployed ACLs that 114 discard packets containing HBH. 116 -> Because network operators deployed ACLs that discard packets 117 containing HBH, network designers stopped defining new HBH Options. 119 -> Because network designers stopped defining new HBH Options, the 120 community was not motivated to fix the implementation problem that 121 cause HBH to become a DoS vector. 123 The purpose of this draft is to break the cycle described above, 124 fixing the problem that caused HBH not actually being utilized in 125 operators' networks so to allow a better leverage of the HBH 126 capability. 128 Driven by the wide deployments of IPv6 and ever-emerging new 129 services, the Hop-by-Hop Options Header is taken as a valuable 130 container for carrying the information to facilitate these new 131 services. 133 This document suggests the desired processing behavior and the 134 migration strategies towards it. 136 2. Modern Router Architecture 138 Modern router architecture design maintains a strict separation of 139 the router control plane and its forwarding plane [RFC6192], as shown 140 in Figure 1. Either the control plane or the forwarding plane is 141 composed of both software and hardware, but each plane is responsible 142 for different functions. 144 +----------------+ 145 | Router Control | 146 | Plane | 147 +------+-+-------+ 148 | | 149 Interface Z 150 | | 151 +------+-+-------+ 152 | Forwarding | 153 Interface X ==[ Plane ]== Interface Y 154 +----------------+ 156 Figure 1. Modern Router Architecture 158 The router control plane supports routing and management functions, 159 handling packets destined to the device as well as building and 160 sending packets originated locally on the device, and also drives the 161 programming of the forwarding plane. The router control plane is 162 generally realized in software on general-purpose processors, and its 163 hardware is usually not optimized for high-speed packet handling. 164 Because of the wide range of functionality, it is more susceptible to 165 security vulnerabilities and a more likely a target for a DoS attack. 167 The forwarding plane is typically responsible for receiving a packet 168 on an incoming interface, performing a lookup to identify the 169 packet's next hop and determine the outgoing interface towards the 170 destination, and forwarding the packet out through the appropriate 171 outgoing interface. Typically, forwarding plane functionality is 172 realized in high-performance Application Specific Integrated Circuits 173 (ASICs) or Network Processors (NPs) that are capable of handling very 174 high packet rates. 176 The router control plane interfaces with its forwarding plane through 177 the Interface Z, as shown in the Figure 1, and the forwarding plane 178 connects to other network devices via Interfaces such as X and Y. 179 Since the router control plane is vulnerable to the DoS attack, 180 usually a traffic filtering mechanism is implemented on Interface Z 181 in order to block unwanted traffic. In order to protect the router 182 control plane, a rate-limiting mechanism is always implemented on 183 this interface. However, such rate limiting mechanism will always 184 cause inconsistent packet drops, which will impact the normal IP 185 forwarding. 187 Semiconductor chip technology has advanced significantly in the last 188 decade, and as such the widely used network processing and forwarding 189 process can now not only forward packets at line speed, but also 190 easily support other feature processing such as QoS for DiffServ/ 191 MPLS, Access Control List (ACL), Firewall, and Deep Packet Inspection 192 (DPI). 194 A Network Processing Unit (NPU) is a non-ASIC based Integrated 195 Circuit (IC) that is programmable through software. It performs all 196 packet header operations between the physical layer interface and the 197 switching fabric such as packet parsing and forwarding, modification, 198 and forwarding. Many equipment vendors implement these functions in 199 fixed function ASICs rather than using "off-the-shelf" NPUs, because 200 of proprietary algorithms. 202 Classification Co-processor is a specialized processor that can be 203 used to lighten the processing load on an NPU by handling the parsing 204 and classification of incoming packets such as IPv6 extended header 205 HBH options processing. This advancement enables network processors 206 to do the general process to handle simple control messages for 207 traffic management, such as signaling for hardware programming, 208 congestion state report, OAM, etc. Industry trend is for intelligent 209 multi-core CPU hardware using modern NPUs for forwarding packets at 210 line rate while still being able to perform other complex tasks such 211 as HBH forwarding options processing without having to punt to the 212 control plane. 214 Many of the packet-processing devices employed in modern switch and 215 router designs are fixed-function ASICs to handle proprietary 216 functions. While these devices can be very efficient for the set of 217 functions they are designed for, they can be very inflexible. There 218 is a tradeoff of price, performance and flexibility when vendors make 219 a choice to use a fixed function ASIC as opposed to NPU. Due to the 220 inflexibility of the fixed function ASIC, tasks that require 221 additional processing such as IPv6 HBH header processing must be 222 punted to the control plane. This problem is still a challenge today 223 and is the reason why operators to protect against control plane DOS 224 attack vector must drop or ignore HBH options. As industry shifts to 225 Merchant Silicon based NPU evolution from fixed function ASIC, the 226 gap will continue to close increasing the viability ubiquitous HBH 227 use cases due to now processing in the forwarding plane. 229 Most modern routers maintain a strict separation between forwarding 230 plane and control plane hardware. Forwarding plane bandwidth and 231 resources are plentiful, while control plane bandwidth and resources 232 are constrained. In order to protect scarce control plane resources, 233 routers enforce policies that restrict access from the forwarding 234 plane to the control plane. Effective policies address packets 235 containing the HBH Options Extension header, because HBH control 236 options require access from the forwarding plane to the control 237 plane. Many network operators perceive HBH Options to be a breach of 238 the separation between the forwarding and control planes. In this 239 case HBH control options would be required to be punted to control 240 plane by fixed function ASICs as well as NPUs. 242 The maximum length of an HBH Options header is 2,048 bytes. A source 243 node can encode hundreds of options in 2,048 bytes. With today's 244 technology it would be cost prohibitive to be able to process 245 hundreds of options with either NPU or proprietary fixed function 246 ASIC. 248 While [RFC8200] required that all nodes must examine and process the 249 Hop-by-Hop Options header, it is now expected that nodes along a 250 packet's delivery path only examine and process the Hop-by-Hop 251 Options header if explicitly configured to do so. This can be 252 beneficial in cases where transit nodes are legacy hardware and the 253 destination endpoint PE is newer NPU based hardware that can process 254 HBH in the forwarding plane. 256 IPv6 Extended Header limitations that need to be addressed to make 257 HBH processing more efficient and viable in the forwarding plane: 259 [RFC8504] defines the IPv6 node requirements and how to protect a 260 node from excessive header chain and excessive header options with 261 various limitations that can be defined on a node. [RFC8883] defines 262 ICMPv6 Errors for discarding packets due to processing limits. Per 263 [RFC8200] HBH options must be processed serially. However, an 264 implementation of options processing can be made to be done with more 265 parallelism in serial processing grouping of similar options to be 266 processed in parallel. 268 The IPv6 standard does not currently limit the header chain length or 269 number of options that can be encoded. 271 Each Option is encoded in a TLV and so processing of a long list of 272 TLVs is expensive. Zero data length encoded options TLVs are a valid 273 option. A DOS vector could be easily generated by encoding 1000 HBH 274 options (Zero data length) in a standard 1500 MTU packet. So now 275 imagine if you have a Christmas tree long header chain to parse each 276 with many options. 278 3. Specification of RFC 8200 280 [RFC8200] defines several IPv6 extension header types, including the 281 Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- 282 by-Hop (HBH) Options header is used to carry optional information 283 that will be examined and processed by every node along a packet's 284 delivery path, and it is identified by a Next Header value of zero in 285 the IPv6 header. 287 The Hop-by-Hop (HBH) Options header contains the following fields: 289 -- Next Header: 8-bit selector, identifies the type of header 290 immediately following the Hop-by-Hop Options header. 292 -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 293 Options header in 8-octet units, not including the first 8 octets. 295 -- Options: Variable-length field, of length such that the complete 296 Hop-by-Hop Options header is an integer multiple of 8 octets long. 298 The Hop-by-Hop (HBH) Options header carries a variable number of 299 "options" that are encoded in the format of type-length-value (TLV). 301 The highest-order two bits (i.e., the ACT bits) of the Option Type 302 specify the action that must be taken if the processing IPv6 node 303 does not recognize the Option Type. The third-highest-order bit 304 (i.e., the CHG bit) of the Option Type specifies whether or not the 305 Option Data of that option can change en route to the packet's final 306 destination. 308 While [RFC2460] required that all nodes must examine and process the 309 Hop-by-Hop Options header, with [RFC8200] it is expected that nodes 310 along a packet's delivery path only examine and process the Hop-by- 311 Hop Options header if explicitly configured to do so. It means that 312 the HBH processing behavior in a node depends on its configuration. 314 However, in the current [RFC8200], there is no explicit specification 315 of the possible configurations. Therefore, the nodes may be 316 configured to ignore the Hop-by-Hop Options header, drop packets 317 containing a Hop-by-Hop Options header, or assign packets containing 318 a Hop-by-Hop Options header to the control plane [RFC8200]. Because 319 of these likely uncertain processing behaviors, new hop-by-hop 320 options are not recommended. 322 4. Common Implementations 324 In the current common implementations, once an IPv6 packet, with its 325 Next Header field set to 0, arrives at a node, it will be directly 326 sent to the control plane of the node. With such implementations, 327 the value of the Next Header field in the IPv6 header is the only 328 trigger for the default processing behavior. The option type of each 329 option carried within the Hop-by-Hop Options header will not even be 330 examined before the packet is sent to the control plane. 332 Very often, such processing behavior is the default configuration on 333 the node, which is embedded in the implementation and cannot be 334 changed or reconfigured. 336 Another critical component of IPv6 HBH processing, in some cases 337 overlooked, is the operator core network which can be designed to use 338 the global Internet routing table for internet traffic and in other 339 cases use an overlay MPLS VPN to carry Internet traffic. 341 In the global Internet routing table scenario where only an underlay 342 global routing table exists, and no VPN overlay carrying customer 343 Internet traffic, the IPv6 HBH options can be used as a DOS attack 344 vector for both the operator nodes, adjacent inter-as peer nodes as 345 well as customer nodes along a path. 347 In a case where the Internet routing table is carried in a MPLS VPN 348 overlay payload, the HBH options header does not impact the operator 349 underlay framework and only impacts the VPN overlay payload and thus 350 the operator underlay topmost label global table routing FEC LSP 351 instantiation is not impacted as the operator underlay is within the 352 operators closed domain. 354 However, HBH options DOS attack vector in the VPN overlay can still 355 impact the customer CE destination end nodes as well as other 356 adjacent inter-as operators that only use underlay global Internet 357 routing table. In an operator closed domain where MPLS VPN overlay 358 is utilized to carry internet traffic, the operator has full control 359 of the underlay and IPv6 Extended header chain length as well as the 360 number of HBH options encoded. 362 In the global routing table scenario for Internet traffic there is no 363 way to control the IPv6 Extended header chain lenghth as well as the 364 number of HBH options encoded. 366 4.1. Historical Reasons 368 When IPv6 was first implemented on high-speed routers, HBH options 369 were not yet well-understood and ASICs were not as capable as they 370 are today. So, early IPv6 implementations dispatched all packets 371 that contain HBH options to their control plane. 373 4.2. Consequences 375 Such implementation introduces a risk of a DoS attack on the control 376 plane of the node, and a large flow of IPv6 packets could congest the 377 control plane, causing other critical functions (including routing 378 and network management) that are executed on the control plane to 379 fail. Rate limiting mechanisms will cause inconsistent packet drops 380 and impact the normal end-to-end IP forwarding of the network 381 services. 383 5. Operators' Typical Processing 385 To mitigate this DoS vulnerability, many operators deployed Access 386 Control Lists (ACLs) that discard all packets containing HBH Options. 388 [RFC6564] shows the Reports from the field indicating that some IP 389 routers deployed within the global Internet are configured either to 390 ignore or to drop packets having a hop-by-hop header. As stated in 391 [RFC7872], many network operators perceive HBH Options to be a breach 392 of the separation between the forwarding and control planes. 393 Therefore, several network operators configured their nodes so as to 394 discard all packets containing the HBH Options Extension Header, 395 while others configured nodes to forward the packet but to ignore the 396 HBH Options. [RFC7045] also states that hop-by-hop options are not 397 handled by many high-speed routers or are processed only on a control 398 plane. 400 Due to such behaviors observed and described in these specifications, 401 new hop-by-hop options are not recommended in [RFC8200] hence the 402 usability of HBH options is severely limited. 404 6. New Services 406 As IPv6 is being rapidly and widely deployed worldwide, more and more 407 applications and network services are migrating to or directly 408 adopting IPv6. More and more new services that require HBH are 409 emerging and the HBH Options header is going to be utilized by the 410 new services in various scenarios. 412 In-situ OAM (IOAM) with IPv6 encapsulation 413 [I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in 414 IPv6 is used to enhance diagnostics of IPv6 networks and complements 415 other mechanisms, such as the IPv6 Performance and Diagnostic Metrics 416 Destination Option described in [RFC8250]. The IOAM data fields are 417 encapsulated in "option data" fields of the Hop-by-Hop Options header 418 if Pre-allocated Tracing Option, Incremental Tracing Option, or Proof 419 of Transit Option are carried [I-D.ietf-ippm-ioam-data], that is, the 420 IOAM performs per hop. 422 Alternate Marking Method can be used as the passive performance 423 measurement tool in an IPv6 domain. The AltMark Option is defined as 424 a new IPv6 extension header option to encode alternate marking 425 technique and Hop-by-Hop Options Header is considered 426 [I-D.ietf-6man-ipv6-alt-mark]. 428 The Minimum Path MTU Hop-by-Hop Option is defined in 429 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 430 forward path between a source host to a destination host. This Hop- 431 by-Hop option is intended to be used in environments like Data 432 Centers and on paths between Data Centers as well as other 433 environments including the general Internet. It provides a useful 434 tool for allowing to better take advantage of paths able to support a 435 large Path MTU. 437 As more services start utilizing the HBH Options header, more packets 438 containing HBH Options are going to be injected into the networks. 439 According to the current common configuration in most network 440 deployments, all the packets of the new services are going to be sent 441 to the control plane of the nodes, with the possible consequence of 442 causing a DoS on the control plane. The packets will be dropped and 443 the normal IP forwarding may be severely impacted. The deployment of 444 new network services involving multi-vendor interoperability will 445 become impossible. 447 7. Requirements 449 * The HBH options header MUST NOT become a possible DDoS Vector. 451 * HBH options SHOULD be designed so that they don't reduce the 452 probability of packet delivery. For example, an intermediate node 453 may discard a packet because it contains more HBH options than the 454 node can process. 456 * HBH processing MUST be efficient. That is, it MUST be possible to 457 produce implementations that perform well at a reasonable cost. 459 * The Router Alert Option MUST NOT impact the processing of other 460 HBH options that should be processed more quickly. 462 * HBH Options MAY influence how a packet is forwarded. However, 463 with the exception of the Router Alert Option, an HBH Option MUST 464 NOT cause control plane state to be created, modified or destroyed 465 on the processing node. As per [RFC6398], protocol developers 466 SHOULD avoid future use of the Router Alert Option. 468 * More requirements are to be added. 470 8. Migration Strategies 472 In order to achieve the desired processing behavior of the HBH 473 options header and facilitate the ever-emerging new services to be 474 deployed in operators' networks across multiple vendors' devices, the 475 migration can happen in three parts as described below: 477 1. The source of the HBH options header encapsulation. 479 The information to be carried in the HBH options header needs to be 480 first categorized and encapsulated into either control options or 481 forwarding options, and then encapsulated in different packets. 483 2. The nodes within the network. 485 The nodes within the network are updated to the proposed behavior 486 introduced in the previous section. 488 3. The edge nodes of the network. 490 The edge nodes should check whether the packet contains an HBH header 491 with control or forwarding option. Packets with a control option may 492 still be filtered and dropped while packets with forwarding option 493 SHOULD be allowed by the ACL. 495 If it is certain that there is no harm that can be introduced by the 496 HBH control options to the nodes and the services, they can also be 497 allowed. 499 Note: During the migration stage, the nodes that are not yet updated 500 will stay with their existing configurations. 502 9. Security Considerations 504 The same as the Security Considerations apply as in [RFC8200] for the 505 part related with the HBH Options header. 507 10. IANA Considerations 509 This document does not include an IANA request. 511 11. Acknowledgements 513 The authors would like to acknowledge Ron Bonica, Fred Baker, Bob 514 Hinden, Stefano Previdi, and Donald Eastlake for their valuable 515 review and comments. 517 12. References 519 12.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, 523 DOI 10.17487/RFC2119, March 1997, 524 . 526 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 527 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 528 December 1998, . 530 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 531 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 532 March 2011, . 534 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 535 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 536 2011, . 538 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 539 of IPv6 Extension Headers", RFC 7045, 540 DOI 10.17487/RFC7045, December 2013, 541 . 543 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 544 "Observations on the Dropping of Packets with IPv6 545 Extension Headers in the Real World", RFC 7872, 546 DOI 10.17487/RFC7872, June 2016, 547 . 549 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 550 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 551 May 2017, . 553 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 554 (IPv6) Specification", STD 86, RFC 8200, 555 DOI 10.17487/RFC8200, July 2017, 556 . 558 12.2. Informative References 560 [I-D.ietf-6man-ipv6-alt-mark] 561 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 562 Pang, "IPv6 Application of the Alternate Marking Method", 563 Work in Progress, Internet-Draft, draft-ietf-6man-ipv6- 564 alt-mark-08, 26 July 2021, 565 . 568 [I-D.ietf-6man-mtu-option] 569 Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU 570 Hop-by-Hop Option", Work in Progress, Internet-Draft, 571 draft-ietf-6man-mtu-option-06, 7 August 2021, 572 . 575 [I-D.ietf-ippm-ioam-data] 576 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 577 for In-situ OAM", Work in Progress, Internet-Draft, draft- 578 ietf-ippm-ioam-data-14, 24 June 2021, 579 . 582 [I-D.ietf-ippm-ioam-ipv6-options] 583 Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", 584 Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- 585 ipv6-options-06, 31 July 2021, 586 . 589 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 590 RFC 2711, DOI 10.17487/RFC2711, October 1999, 591 . 593 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 594 Performance and Diagnostic Metrics (PDM) Destination 595 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 596 . 598 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 599 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 600 January 2019, . 602 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 603 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 604 September 2020, . 606 Authors' Addresses 608 Shuping Peng 609 Huawei Technologies 610 Beijing 611 China 613 Email: pengshuping@huawei.com 615 Zhenbin Li 616 Huawei Technologies 617 Beijing 618 China 620 Email: lizhenbin@huawei.com 622 Chongfeng Xie 623 China Telecom 624 China 626 Email: xiechf@chinatelecom.cn 628 Zhuangzhuang Qin 629 China Unicom 630 Beijing 631 China 633 Email: qinzhuangzhuang@chinaunicom.cn 634 Gyan Mishra 635 Verizon Inc. 636 United States of America 638 Email: gyan.s.mishra@verizon.com