idnits 2.17.1 draft-peng-v6ops-hbh-03.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 (January 22, 2021) is 1189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 384, 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-02 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-04 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-01) exists of draft-li-6man-hbh-fwd-hdr-00 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: July 26, 2021 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 G. Mishra 10 Verizon Inc. 11 January 22, 2021 13 Processing of the Hop-by-Hop Options Header 14 draft-peng-v6ops-hbh-03 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, and 29 proposed, processing behavior of the HBH and the migration strategies 30 towards 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 July 26, 2021. 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 slow path 97 (i.e., the control plane) of the node. The option type of each 98 option carried within the Hop-by-Hop Options header will not even be 99 examined before the packet is sent to the slow path. Very often, 100 such processing behavior is the default configuration or, even worse, 101 is the only behavior of 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. Classification Co-processor is a 202 specialized processor that can be used to lighten the processing load 203 on an NPU by handling the parsing and classification of incoming 204 packets such as IPv6 extended header HBH options processing. This 205 advancement enables network processors to do the general process to 206 handle simple control messages for traffic management, such as 207 signaling for hardware programming, congestion state report, OAM, 208 etc. Industry trend is for intelligent multi-core CPU fast path 209 hardware using modern NPUs for forwarding packets at line rate while 210 still being able to perform other complex tasks such as HBH 211 forwarding options processing without having to punt to slow path. 213 Many of the fast-path packet-processing devices employed in modern 214 switch and router designs are fixed-function ASICs to handle 215 proprietary functions. While these devices can be very efficient for 216 the set of functions they are designed for, they can be very 217 inflexible. There is a tradeoff of price, performance and 218 flexibility when vendors make a choice to use a fixed function ASIC 219 as opposed to NPU. Due to the inflexibility of the fixed function 220 ASIC, tasks that require additional processing such as IPv6 HBH 221 header processing must be punted to the slow path. This problem is 222 still a challenge today and is the reason why operators to protect 223 against control plane DOS attack vector must drop or ignore HBH 224 options. As industry shifts to Merchant Silicon based NPU evolution 225 from fixed function ASIC, the gap will continue to close increasing 226 the viability ubiquitous HBH use cases due to now processing in the 227 fast path. 229 Most modern routers maintain a strict separation between forwarding 230 plane and control plane hardware. Forwarding plane "fast path" 231 bandwidth and resources are plentiful, while control plane "slow 232 path" bandwidth and resources are constrained. In order to protect 233 scarce control plane resources, routers enforce policies that 234 restrict access from the forwarding plane to the control plane. 235 Effective policies address packets containing the HBH Options 236 Extension header, because HBH control options require access from the 237 forwarding plane to the control plane. Many network operators 238 perceive HBH Options to be a breach of the separation between the 239 forwarding and control planes. In this case HBH control options 240 would be required to be punted to slow path by fixed function ASICs 241 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 fast path. 257 IPv6 Extended Header limitations that need to be addressed to make 258 HBH processing more efficient and viable in the fast path: 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 a slow processing path [RFC8200]. 320 Because of these likely uncertain processing behaviors, new hop-by- 321 hop 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 slow path (i.e., the control plane) of the node. With 328 such implementations, the value of the Next Header field in the IPv6 329 header is the only trigger for the default processing behavior. The 330 option type of each option carried within the Hop-by-Hop Options 331 header will not even be examined before the packet is sent to the 332 slow path. 334 Very often, such processing behavior is the default configuration on 335 the node, which is embedded in the implementation and cannot be 336 changed or reconfigured. 338 Another critical component of IPv6 HBH processing which is in some 339 cases is overlooked is the operator core network which can be 340 designed to use the global Internet routing table for internet 341 traffic and in other cases use an overlay MPLS VPN to carry Internet 342 traffic. In the global Internet routing table scenario where only an 343 underlay global routing table exists, and no VPN overlay carrying 344 customer Internet traffic, the IPv6 HBH options can be used as a DOS 345 attack vector for both the operator nodes, adjacent inter-as peer 346 nodes as well as customer nodes along a path. In a case where the 347 Internet routing table is carried in a MPLS VPN overlay payload, the 348 HBH options header does not impact the operator underlay framework 349 and only impacts the VPN overlay payload and thus the operator 350 underlay topmost label global table routing FEC LSP instantiation is 351 not impacted as the operator underlay is within the operators closed 352 domain. However HBH options DOS attack vector in the VPN overlay can 353 still impact the customer CE destination end nodes as well as other 354 adjacent inter-as operators that only use underlay global Internet 355 routing table. In an operator closed domain where MPLS VPN overlay 356 is utilized to carry internet traffic, the operator has full control 357 of the underlay and IPv6 Extended header chain length as well as the 358 number of HBH options encoded. However in contrast, in the global 359 routing table scenario for Internet traffic there is no way to 360 control the IPv6 Extended header chain lenghth as well as the number 361 of HBH forward or HBH control options encoded. 363 4.1. Historical Reasons 365 When IPv6 was first implemented on high-speed routers, HBH options 366 were not yet well-understood and ASICs were not as capable as they 367 are today. So, early IPv6 implementations dispatched all packets 368 that contain HBH options to their slow path. 370 4.2. Consequences 372 Such implementation introduces a risk of a DoS attack on the control 373 plane of the node, and a large flow of IPv6 packets could congest the 374 slow path, causing other critical functions (including routing and 375 network management) that are executed on the control plane to fail. 376 Rate limiting mechanisms will cause inconsistent packet drops and 377 impact the normal end-to-end IP forwarding of the network services. 379 5. Operators' Typical Processing 381 To mitigate this DoS vulnerability, many operators deployed Access 382 Control Lists (ACLs) that discard all packets containing HBH Options. 384 [RFC6564] shows the Reports from the field indicating that some IP 385 routers deployed within the global Internet are configured either to 386 ignore or to drop packets having a hop-by-hop header. As stated in 387 [RFC7872], many network operators perceive HBH Options to be a breach 388 of the separation between the forwarding and control planes. 389 Therefore, several network operators configured their nodes so as to 390 discard all packets containing the HBH Options Extension Header, 391 while others configured nodes to forward the packet but to ignore the 392 HBH Options. [RFC7045] also states that hop-by-hop options are not 393 handled by many high-speed routers or are processed only on a slow 394 path. 396 Due to such behaviors observed and described in these specifications, 397 new hop-by-hop options are not recommended in [RFC8200] hence the 398 usability of HBH options is severely limited. 400 6. New Services 402 As IPv6 is being rapidly and widely deployed worldwide, more and more 403 applications and network services are migrating to or directly 404 adopting IPv6. More and more new services that require HBH are 405 emerging and the HBH Options header is going to be utilized by the 406 new services in various scenarios. 408 In-situ OAM (IOAM) with IPv6 encapsulation 409 [I-D.ietf-ippm-ioam-ipv6-options] is one of the examples. IOAM in 410 IPv6 is used to enhance diagnostics of IPv6 networks and complements 411 other mechanisms, such as the IPv6 Performance and Diagnostic Metrics 412 Destination Option described in [RFC8250]. The IOAM data fields are 413 encapsulated in "option data" fields of the Hop-by-Hop Options header 414 if Pre-allocated Tracing Option, Incremental Tracing Option, or Proof 415 of Transit Option are carried [I-D.ietf-ippm-ioam-data], that is, the 416 IOAM performs per hop. 418 Alternate Marking Method can be used as the passive performance 419 measurement tool in an IPv6 domain. The AltMark Option is defined as 420 a new IPv6 extension header option to encode alternate marking 421 technique and Hop-by-Hop Options Header is considered 422 [I-D.ietf-6man-ipv6-alt-mark]. 424 The Minimum Path MTU Hop-by-Hop Option is defined in 425 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 426 forward path between a source host to a destination host. This Hop- 427 by-Hop option is intended to be used in environments like Data 428 Centers and on paths between Data Centers as well as other 429 environments including the general Internet. It provides a useful 430 tool for allowing to better take advantage of paths able to support a 431 large Path MTU. 433 As more services start utilizing the HBH Options header, more packets 434 containing HBH Options are going to be injected into the networks. 435 According to the current common configuration in most network 436 deployments, all the packets of the new services are going to be sent 437 to the control plane of the nodes, with the possible consequence of 438 causing a DoS on the control plane. The packets will be dropped and 439 the normal IP forwarding may be severely impacted. The deployment of 440 new network services involving multi-vendor interoperability will 441 become impossible. 443 7. The Desired Processing Behavior 445 The following requirements SHOULD be met: 447 o The control plane SHOULD be protected from undesired traffic. 449 -* The HBH options header SHOULD NOT be directly sent to the control 450 plane once the packets are received since these options may not aim 451 for the control plane. 453 -* The HBH options that are not supposed to be processed by the 454 control plane SHOULD NOT be sent to the control plane, potentially 455 causing the DoS attack. 457 o Since generally the two types of HBH options (control plane (e.g., 458 Route Alert Option [RFC2711]) and forwarding plane (e.g., AltMark 459 Option [I-D.ietf-6man-ipv6-alt-mark])) serve different purposes 460 and require different processing procedures on a node, they should 461 be encoded separately and carried in different packets. 463 Note: More details on the two types of HBH options can be found in 464 [I-D.li-6man-hbh-fwd-hdr]. 466 o The packets carrying the HBH Forwarding Options are supposed to be 467 maintained in the forwarding plane rather than being directly sent 468 up to the control plane. While the packets carrying the HBH 469 Control Options are supposed to be sent to the control plane. 471 o The source node SHOULD NOT encode the HBH Options that exceed the 472 maximum length of an HBH Options header i.e. 2,048 bytes. 474 o The source node SHOULD NOT encode the number of HBH Options that 475 exceeds the lowest processing capability of the nodes along the 476 path. 478 o The source node SHOULD NOT encode the HBH Options that exceed the 479 maximum overall length of the IPv6 extensions header chain. 481 o The options aimed for the control plane are better if they do not 482 consume the forwarding plane resources. 484 o A simple and efficient way to discriminate the two types of HBH 485 options is required. 487 o The new deployments should be compatible with the existing 488 deployments, since default configuration of some devices running 489 in the networks cannot be changed or reconfigured. The update of 490 the networks in operation will usually take time. 492 o If the IPv6 extension header including the HBH options header of a 493 packet cannot be recognized by the node, or the option in the HBH 494 header is unknown to the node, and the node is not the destination 495 of the packet, the packet SHOULD NOT be dropped or sent to the 496 control plane, rather this unrecognized extension header should be 497 skipped and the rest of the packet should be processed. 499 8. Migration Strategies 501 In order to achieve the desired processing behavior of the HBH 502 options header and facilitate the ever-emerging new services to be 503 deployed in operators' networks across multiple vendors' devices, the 504 migration can happen in three parts as described below: 506 1. The source of the HBH options header encapsulation. 508 The information to be carried in the HBH options header needs to be 509 first categorized and encapsulated into either control options or 510 forwarding options, and then encapsulated in different packets. 512 2. The nodes within the network. 514 The nodes within the network are updated to the proposed behavior 515 introduced in the previous section. 517 3. The edge nodes of the network. 519 The edge nodes should check whether the packet contains an HBH header 520 with control or forwarding option. Packets with a control option may 521 still be filtered and dropped while packets with forwarding option 522 SHOULD be allowed by the ACL. 524 If it is certain that there is no harm that can be introduced by the 525 HBH control options to the nodes and the services, they can also be 526 allowed. 528 Note: During the migration stage, the nodes that are not yet updated 529 will stay with their existing configurations. 531 9. Security Considerations 533 The same as the Security Considerations apply as in [RFC8200] for the 534 part related with the HBH Options header. 536 10. IANA Considerations 538 This document does not include an IANA request. 540 11. Acknowledgements 542 The authors would like to acknowledge Ron Bonica, Fred Baker, Bob 543 Hinden, Stefano Previdi, and Donald Eastlake for their valuable 544 review and comments. 546 12. References 548 12.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 556 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 557 December 1998, . 559 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 560 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 561 March 2011, . 563 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 564 of IPv6 Extension Headers", RFC 7045, 565 DOI 10.17487/RFC7045, December 2013, 566 . 568 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 569 "Observations on the Dropping of Packets with IPv6 570 Extension Headers in the Real World", RFC 7872, 571 DOI 10.17487/RFC7872, June 2016, 572 . 574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 576 May 2017, . 578 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 579 (IPv6) Specification", STD 86, RFC 8200, 580 DOI 10.17487/RFC8200, July 2017, 581 . 583 12.2. Informative References 585 [I-D.ietf-6man-ipv6-alt-mark] 586 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 587 Pang, "IPv6 Application of the Alternate Marking Method", 588 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 589 October 2020. 591 [I-D.ietf-6man-mtu-option] 592 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 593 by-Hop Option", draft-ietf-6man-mtu-option-04 (work in 594 progress), October 2020. 596 [I-D.ietf-ippm-ioam-data] 597 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 598 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 599 progress), November 2020. 601 [I-D.ietf-ippm-ioam-ipv6-options] 602 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 603 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 604 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 605 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 606 ipv6-options-04 (work in progress), November 2020. 608 [I-D.li-6man-hbh-fwd-hdr] 609 Li, Z. and S. Peng, "Hop-by-Hop Forwarding Options 610 Header", draft-li-6man-hbh-fwd-hdr-00 (work in progress), 611 July 2020. 613 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 614 RFC 2711, DOI 10.17487/RFC2711, October 1999, 615 . 617 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 618 Performance and Diagnostic Metrics (PDM) Destination 619 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 620 . 622 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 623 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 624 January 2019, . 626 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 627 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 628 September 2020, . 630 Authors' Addresses 632 Shuping Peng 633 Huawei Technologies 634 Beijing 635 China 637 Email: pengshuping@huawei.com 639 Zhenbin Li 640 Huawei Technologies 641 Beijing 642 China 644 Email: lizhenbin@huawei.com 646 Chongfeng Xie 647 China Telecom 648 China 650 Email: xiechf@chinatelecom.cn 652 Zhuangzhuang Qin 653 China Unicom 654 Beijing 655 China 657 Email: qinzhuangzhuang@chinaunicom.cn 658 Gyan Mishra 659 Verizon Inc. 660 USA 662 Email: gyan.s.mishra@verizon.com