idnits 2.17.1 draft-peng-v6ops-hbh-04.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 (June 30, 2021) is 1029 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 389, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-04 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-05 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: January 1, 2022 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 G. Mishra 10 Verizon Inc. 11 June 30, 2021 13 Processing of the Hop-by-Hop Options Header 14 draft-peng-v6ops-hbh-04 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 desired 29 processing behavior of the HBH and the migration strategies towards 30 it are also 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 January 1, 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 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. Modern Router Architecture . . . . . . . . . . . . . . . . . 3 75 3. Specification of RFC 8200 . . . . . . . . . . . . . . . . . . 6 76 4. Common Implementations . . . . . . . . . . . . . . . . . . . 7 77 4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 8 78 4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 8 79 5. Operators' Typical Processing . . . . . . . . . . . . . . . . 9 80 6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. The Desired Processing Behavior . . . . . . . . . . . . . . . 10 82 8. Migration Strategies . . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 12.2. Informative References . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 The purpose of this draft is to break the cycle described above, 125 fixing the problem that caused HBH not actually being utilized in 126 operators' networks so to allow a better leverage of the HBH 127 capability. 129 Driven by the wide deployments of IPv6 and ever-emerging new 130 services, the Hop-by-Hop Options Header is taken as a valuable 131 container for carrying the information to facilitate these new 132 services. 134 This document suggests the desired processing behavior and the 135 migration strategies towards it. 137 2. Modern Router Architecture 139 Modern router architecture design maintains a strict separation of 140 the router control plane and its forwarding plane [RFC6192], as shown 141 in Figure 1. Either the control plane or the forwarding plane is 142 composed of both software and hardware, but each plane is responsible 143 for different functions. 145 +----------------+ 146 | Router Control | 147 | Plane | 148 +------+-+-------+ 149 | | 150 Interface Z 151 | | 152 +------+-+-------+ 153 | Forwarding | 154 Interface X ==[ Plane ]== Interface Y 155 +----------------+ 157 Figure 1. Modern Router Architecture 159 The router control plane supports routing and management functions, 160 handling packets destined to the device as well as building and 161 sending packets originated locally on the device, and also drives the 162 programming of the forwarding plane. The router control plane is 163 generally realized in software on general-purpose processors, and its 164 hardware is usually not optimized for high-speed packet handling. 165 Because of the wide range of functionality, it is more susceptible to 166 security vulnerabilities and a more likely a target for a DoS attack. 168 The forwarding plane is typically responsible for receiving a packet 169 on an incoming interface, performing a lookup to identify the 170 packet's next hop and determine the outgoing interface towards the 171 destination, and forwarding the packet out through the appropriate 172 outgoing interface. Typically, forwarding plane functionality is 173 realized in high-performance Application Specific Integrated Circuits 174 (ASICs) or Network Processors (NPs) that are capable of handling very 175 high packet rates. 177 The router control plane interfaces with its forwarding plane through 178 the Interface Z, as shown in the Figure 1, and the forwarding plane 179 connects to other network devices via Interfaces such as X and Y. 180 Since the router control plane is vulnerable to the DoS attack, 181 usually a traffic filtering mechanism is implemented on Interface Z 182 in order to block unwanted traffic. In order to protect the router 183 control plane, a rate-limiting mechanism is always implemented on 184 this interface. However, such rate limiting mechanism will always 185 cause inconsistent packet drops, which will impact the normal IP 186 forwarding. 188 Semiconductor chip technology has advanced significantly in the last 189 decade, and as such the widely used network processing and forwarding 190 process can now not only forward packets at line speed, but also 191 easily support other feature processing such as QoS for DiffServ/ 192 MPLS, Access Control List (ACL), Firewall, and Deep Packet Inspection 193 (DPI). 195 A Network Processing Unit (NPU) is a non-ASIC based Integrated 196 Circuit (IC) that is programmable through software. It performs all 197 packet header operations between the physical layer interface and the 198 switching fabric such as packet parsing and forwarding, modification, 199 and forwarding. Many equipment vendors implement these functions in 200 fixed function ASICs rather than using "off-the-shelf" NPUs, because 201 of proprietary algorithms. 203 Classification Co-processor is a specialized processor that can be 204 used to lighten the processing load on an NPU by handling the parsing 205 and classification of incoming packets such as IPv6 extended header 206 HBH options processing. This advancement enables network processors 207 to do the general process to handle simple control messages for 208 traffic management, such as signaling for hardware programming, 209 congestion state report, OAM, etc. Industry trend is for intelligent 210 multi-core CPU hardware using modern NPUs for forwarding packets at 211 line rate while still being able to perform other complex tasks such 212 as HBH forwarding options processing without having to punt to the 213 control plane. 215 Many of the packet-processing devices employed in modern switch and 216 router designs are fixed-function ASICs to handle proprietary 217 functions. While these devices can be very efficient for the set of 218 functions they are designed for, they can be very inflexible. There 219 is a tradeoff of price, performance and flexibility when vendors make 220 a choice to use a fixed function ASIC as opposed to NPU. Due to the 221 inflexibility of the fixed function ASIC, tasks that require 222 additional processing such as IPv6 HBH header processing must be 223 punted to the control plane. This problem is still a challenge today 224 and is the reason why operators to protect against control plane DOS 225 attack vector must drop or ignore HBH options. As industry shifts to 226 Merchant Silicon based NPU evolution from fixed function ASIC, the 227 gap will continue to close increasing the viability ubiquitous HBH 228 use cases due to now processing in the forwarding plane. 230 Most modern routers maintain a strict separation between forwarding 231 plane and control plane hardware. Forwarding plane bandwidth and 232 resources are plentiful, while control plane bandwidth and resources 233 are constrained. In order to protect scarce control plane resources, 234 routers enforce policies that restrict access from the forwarding 235 plane to the control plane. Effective policies address packets 236 containing the HBH Options Extension header, because HBH control 237 options require access from the forwarding plane to the control 238 plane. Many network operators perceive HBH Options to be a breach of 239 the separation between the forwarding and control planes. In this 240 case HBH control options would be required to be punted to control 241 plane by fixed function ASICs as well as NPUs. 243 The maximum length of an HBH Options header is 2,048 bytes. A source 244 node can encode hundreds of options in 2,048 bytes. With today's 245 technology it would be cost prohibitive to be able to process 246 hundreds of options with either NPU or proprietary fixed function 247 ASIC. 249 While [RFC8200] required that all nodes must examine and process the 250 Hop-by-Hop Options header, it is now expected that nodes along a 251 packet's delivery path only examine and process the Hop-by-Hop 252 Options header if explicitly configured to do so. This can be 253 beneficial in cases where transit nodes are legacy hardware and the 254 destination endpoint PE is newer NPU based hardware that can process 255 HBH in the forwarding plane. 257 IPv6 Extended Header limitations that need to be addressed to make 258 HBH processing more efficient and viable in the forwarding plane: 260 [RFC8504] defines the IPv6 node requirements and how to protect a 261 node from excessive header chain and excessive header options with 262 various limitations that can be defined on a node. [RFC8883] defines 263 ICMPv6 Errors for discarding packets due to processing limits. Per 264 [RFC8200] HBH options must be processed serially. However, an 265 implementation of options processing can be made to be done with more 266 parallelism in serial processing grouping of similar options to be 267 processed in parallel. 269 The IPv6 standard does not currently limit the header chain length or 270 number of options that can be encoded. 272 Each Option is encoded in a TLV and so processing of a long list of 273 TLVs is expensive. Zero data length encoded options TLVs are a valid 274 option. A DOS vector could be easily generated by encoding 1000 HBH 275 options (Zero data length) in a standard 1500 MTU packet. So now 276 imagine if you have a Christmas tree long header chain to parse each 277 with many options. 279 3. Specification of RFC 8200 281 [RFC8200] defines several IPv6 extension header types, including the 282 Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- 283 by-Hop (HBH) Options header is used to carry optional information 284 that will be examined and processed by every node along a packet's 285 delivery path, and it is identified by a Next Header value of zero in 286 the IPv6 header. 288 The Hop-by-Hop (HBH) Options header contains the following fields: 290 -- Next Header: 8-bit selector, identifies the type of header 291 immediately following the Hop-by-Hop Options header. 293 -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 294 Options header in 8-octet units, not including the first 8 octets. 296 -- Options: Variable-length field, of length such that the complete 297 Hop-by-Hop Options header is an integer multiple of 8 octets long. 299 The Hop-by-Hop (HBH) Options header carries a variable number of 300 "options" that are encoded in the format of type-length-value (TLV). 302 The highest-order two bits (i.e., the ACT bits) of the Option Type 303 specify the action that must be taken if the processing IPv6 node 304 does not recognize the Option Type. The third-highest-order bit 305 (i.e., the CHG bit) of the Option Type specifies whether or not the 306 Option Data of that option can change en route to the packet's final 307 destination. 309 While [RFC2460] required that all nodes must examine and process the 310 Hop-by-Hop Options header, with [RFC8200] it is expected that nodes 311 along a packet's delivery path only examine and process the Hop-by- 312 Hop Options header if explicitly configured to do so. It means that 313 the HBH processing behavior in a node depends on its configuration. 315 However, in the current [RFC8200], there is no explicit specification 316 of the possible configurations. Therefore, the nodes may be 317 configured to ignore the Hop-by-Hop Options header, drop packets 318 containing a Hop-by-Hop Options header, or assign packets containing 319 a Hop-by-Hop Options header to the control plane [RFC8200]. Because 320 of these likely uncertain processing behaviors, new hop-by-hop 321 options are not recommended. 323 4. Common Implementations 325 In the current common implementations, once an IPv6 packet, with its 326 Next Header field set to 0, arrives at a node, it will be directly 327 sent to the control plane of the node. With such implementations, 328 the value of the Next Header field in the IPv6 header is the only 329 trigger for the default processing behavior. The option type of each 330 option carried within the Hop-by-Hop Options header will not even be 331 examined before the packet is sent to the control plane. 333 Very often, such processing behavior is the default configuration on 334 the node, which is embedded in the implementation and cannot be 335 changed or reconfigured. 337 Another critical component of IPv6 HBH processing, in some cases 338 overlooked, is the operator core network which can be designed to use 339 the global Internet routing table for internet traffic and in other 340 cases use an overlay MPLS VPN to carry Internet traffic. 342 In the global Internet routing table scenario where only an underlay 343 global routing table exists, and no VPN overlay carrying customer 344 Internet traffic, the IPv6 HBH options can be used as a DOS attack 345 vector for both the operator nodes, adjacent inter-as peer nodes as 346 well as customer nodes along a path. 348 In a case where the Internet routing table is carried in a MPLS VPN 349 overlay payload, the HBH options header does not impact the operator 350 underlay framework and only impacts the VPN overlay payload and thus 351 the operator underlay topmost label global table routing FEC LSP 352 instantiation is not impacted as the operator underlay is within the 353 operators closed domain. 355 However, HBH options DOS attack vector in the VPN overlay can still 356 impact the customer CE destination end nodes as well as other 357 adjacent inter-as operators that only use underlay global Internet 358 routing table. In an operator closed domain where MPLS VPN overlay 359 is utilized to carry internet traffic, the operator has full control 360 of the underlay and IPv6 Extended header chain length as well as the 361 number of HBH options encoded. 363 In the global routing table scenario for Internet traffic there is no 364 way to control the IPv6 Extended header chain lenghth as well as the 365 number of HBH options encoded. 367 4.1. Historical Reasons 369 When IPv6 was first implemented on high-speed routers, HBH options 370 were not yet well-understood and ASICs were not as capable as they 371 are today. So, early IPv6 implementations dispatched all packets 372 that contain HBH options to their control plane. 374 4.2. Consequences 376 Such implementation introduces a risk of a DoS attack on the control 377 plane of the node, and a large flow of IPv6 packets could congest the 378 control plane, causing other critical functions (including routing 379 and network management) that are executed on the control plane to 380 fail. Rate limiting mechanisms will cause inconsistent packet drops 381 and impact the normal end-to-end IP forwarding of the network 382 services. 384 5. Operators' Typical Processing 386 To mitigate this DoS vulnerability, many operators deployed Access 387 Control Lists (ACLs) that discard all packets containing HBH Options. 389 [RFC6564] shows the Reports from the field indicating that some IP 390 routers deployed within the global Internet are configured either to 391 ignore or to drop packets having a hop-by-hop header. As stated in 392 [RFC7872], many network operators perceive HBH Options to be a breach 393 of the separation between the forwarding and control planes. 394 Therefore, several network operators configured their nodes so as to 395 discard all packets containing the HBH Options Extension Header, 396 while others configured nodes to forward the packet but to ignore the 397 HBH Options. [RFC7045] also states that hop-by-hop options are not 398 handled by many high-speed routers or are processed only on a control 399 plane. 401 Due to such behaviors observed and described in these specifications, 402 new hop-by-hop options are not recommended in [RFC8200] hence the 403 usability of HBH options is severely limited. 405 6. New Services 407 As IPv6 is being rapidly and widely deployed worldwide, more and more 408 applications and network services are migrating to or directly 409 adopting IPv6. More and more new services that require HBH are 410 emerging and the HBH Options header is going to be utilized by the 411 new services in various scenarios. 413 In-situ OAM (IOAM) with IPv6 encapsulation 414 [I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in 415 IPv6 is used to enhance diagnostics of IPv6 networks and complements 416 other mechanisms, such as the IPv6 Performance and Diagnostic Metrics 417 Destination Option described in [RFC8250]. The IOAM data fields are 418 encapsulated in "option data" fields of the Hop-by-Hop Options header 419 if Pre-allocated Tracing Option, Incremental Tracing Option, or Proof 420 of Transit Option are carried [I-D.ietf-ippm-ioam-data], that is, the 421 IOAM performs per hop. 423 Alternate Marking Method can be used as the passive performance 424 measurement tool in an IPv6 domain. The AltMark Option is defined as 425 a new IPv6 extension header option to encode alternate marking 426 technique and Hop-by-Hop Options Header is considered 427 [I-D.ietf-6man-ipv6-alt-mark]. 429 The Minimum Path MTU Hop-by-Hop Option is defined in 430 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 431 forward path between a source host to a destination host. This Hop- 432 by-Hop option is intended to be used in environments like Data 433 Centers and on paths between Data Centers as well as other 434 environments including the general Internet. It provides a useful 435 tool for allowing to better take advantage of paths able to support a 436 large Path MTU. 438 As more services start utilizing the HBH Options header, more packets 439 containing HBH Options are going to be injected into the networks. 440 According to the current common configuration in most network 441 deployments, all the packets of the new services are going to be sent 442 to the control plane of the nodes, with the possible consequence of 443 causing a DoS on the control plane. The packets will be dropped and 444 the normal IP forwarding may be severely impacted. The deployment of 445 new network services involving multi-vendor interoperability will 446 become impossible. 448 7. The Desired Processing Behavior 450 The following requirements SHOULD be met: 452 o The control plane SHOULD be protected from undesired traffic. 454 -* The HBH options header SHOULD NOT be directly sent to the control 455 plane once the packets are received since these options may not aim 456 for the control plane. 458 -* The HBH options that are not supposed to be processed by the 459 control plane SHOULD NOT be sent to the control plane, potentially 460 causing the DoS attack. 462 o Since generally the two types of HBH options (control plane (e.g., 463 Route Alert Option [RFC2711]) and forwarding plane (e.g., AltMark 464 Option [I-D.ietf-6man-ipv6-alt-mark])) serve different purposes 465 and require different processing procedures on a node, they should 466 be encoded separately and carried in different packets. 468 o The packets carrying the HBH Forwarding Options are supposed to be 469 maintained in the forwarding plane rather than being directly sent 470 up to the control plane. While the packets carrying the HBH 471 Control Options are supposed to be sent to the control plane. 473 o The source node SHOULD NOT encode the HBH Options that exceed the 474 maximum length of an HBH Options header i.e. 2,048 bytes. 476 o The source node SHOULD NOT encode the number of HBH Options that 477 exceeds the lowest processing capability of the nodes along the 478 path. 480 o The source node SHOULD NOT encode the HBH Options that exceed the 481 maximum overall length of the IPv6 extensions header chain. 483 o The options aimed for the control plane are better if they do not 484 consume the forwarding plane resources. 486 o A simple and efficient way to discriminate the two types of HBH 487 options is required. 489 o The new deployments should be compatible with the existing 490 deployments, since default configuration of some devices running 491 in the networks cannot be changed or reconfigured. The update of 492 the networks in operation will usually take time. 494 o If the IPv6 extension header including the HBH options header of a 495 packet cannot be recognized by the node, or the option in the HBH 496 header is unknown to the node, and the node is not the destination 497 of the packet, the packet SHOULD NOT be dropped or sent to the 498 control plane, rather this unrecognized extension header should be 499 skipped and the rest of the packet should be processed. 501 8. Migration Strategies 503 In order to achieve the desired processing behavior of the HBH 504 options header and facilitate the ever-emerging new services to be 505 deployed in operators' networks across multiple vendors' devices, the 506 migration can happen in three parts as described below: 508 1. The source of the HBH options header encapsulation. 510 The information to be carried in the HBH options header needs to be 511 first categorized and encapsulated into either control options or 512 forwarding options, and then encapsulated in different packets. 514 2. The nodes within the network. 516 The nodes within the network are updated to the proposed behavior 517 introduced in the previous section. 519 3. The edge nodes of the network. 521 The edge nodes should check whether the packet contains an HBH header 522 with control or forwarding option. Packets with a control option may 523 still be filtered and dropped while packets with forwarding option 524 SHOULD be allowed by the ACL. 526 If it is certain that there is no harm that can be introduced by the 527 HBH control options to the nodes and the services, they can also be 528 allowed. 530 Note: During the migration stage, the nodes that are not yet updated 531 will stay with their existing configurations. 533 9. Security Considerations 535 The same as the Security Considerations apply as in [RFC8200] for the 536 part related with the HBH Options header. 538 10. IANA Considerations 540 This document does not include an IANA request. 542 11. Acknowledgements 544 The authors would like to acknowledge Ron Bonica, Fred Baker, Bob 545 Hinden, Stefano Previdi, and Donald Eastlake for their valuable 546 review and comments. 548 12. References 550 12.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 558 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 559 December 1998, . 561 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 562 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 563 March 2011, . 565 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 566 of IPv6 Extension Headers", RFC 7045, 567 DOI 10.17487/RFC7045, December 2013, 568 . 570 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 571 "Observations on the Dropping of Packets with IPv6 572 Extension Headers in the Real World", RFC 7872, 573 DOI 10.17487/RFC7872, June 2016, 574 . 576 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 577 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 578 May 2017, . 580 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 581 (IPv6) Specification", STD 86, RFC 8200, 582 DOI 10.17487/RFC8200, July 2017, 583 . 585 12.2. Informative References 587 [I-D.ietf-6man-ipv6-alt-mark] 588 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 589 Pang, "IPv6 Application of the Alternate Marking Method", 590 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March 591 2021. 593 [I-D.ietf-6man-mtu-option] 594 Hinden, R. M. and G. Fairhurst, "IPv6 Minimum Path MTU 595 Hop-by-Hop Option", draft-ietf-6man-mtu-option-05 (work in 596 progress), April 2021. 598 [I-D.ietf-ippm-ioam-data] 599 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 600 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 601 progress), February 2021. 603 [I-D.ietf-ippm-ioam-ipv6-options] 604 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 605 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 606 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 607 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 608 ipv6-options-05 (work in progress), February 2021. 610 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 611 RFC 2711, DOI 10.17487/RFC2711, October 1999, 612 . 614 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 615 Performance and Diagnostic Metrics (PDM) Destination 616 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 617 . 619 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 620 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 621 January 2019, . 623 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 624 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 625 September 2020, . 627 Authors' Addresses 629 Shuping Peng 630 Huawei Technologies 631 Beijing 632 China 634 Email: pengshuping@huawei.com 636 Zhenbin Li 637 Huawei Technologies 638 Beijing 639 China 641 Email: lizhenbin@huawei.com 643 Chongfeng Xie 644 China Telecom 645 China 647 Email: xiechf@chinatelecom.cn 649 Zhuangzhuang Qin 650 China Unicom 651 Beijing 652 China 654 Email: qinzhuangzhuang@chinaunicom.cn 656 Gyan Mishra 657 Verizon Inc. 658 USA 660 Email: gyan.s.mishra@verizon.com