idnits 2.17.1 draft-peng-v6ops-hbh-02.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 (December 1, 2020) is 1241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 269, but not defined == Unused Reference: 'I-D.li-6man-hbh-fwd-hdr' is defined on line 473, 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-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 (~~), 8 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: June 4, 2021 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 G. Mishra 10 Verizon Inc. 11 December 1, 2020 13 Processing of the Hop-by-Hop Options Header 14 draft-peng-v6ops-hbh-02 16 Abstract 18 This document describes the processing of the Hop-by-Hop Options 19 Header in today's routers in the aspects of standards specification, 20 common implementations, and default operations. This document 21 outlines the reasons why the Hop-by-Hop Options Header is rarely 22 utilized in current networks. In addition, this document describes 23 how the HBH could be used as a powerful mechanism allowing deployment 24 and operations of new services requiring a more optimized way to 25 leverage network resources of an infrastructure. The Hop-by-Hop 26 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 RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on June 4, 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Modern Router Architecture . . . . . . . . . . . . . . . . . 3 74 3. Specification of RFC8200 . . . . . . . . . . . . . . . . . . 4 75 4. Common Implementations . . . . . . . . . . . . . . . . . . . 5 76 4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 6 77 4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 6 78 5. Operators' typical processing . . . . . . . . . . . . . . . . 6 79 6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 7 80 7. The desired processing behavior . . . . . . . . . . . . . . . 7 81 8. Migration strategies . . . . . . . . . . . . . . . . . . . . 8 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 12.2. Informative References . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 Due to the historical reasons, such as incapable ASICs, limited IPv6 93 deployments and few service requirements, the most common 94 implementation on the processing of the Hop-by-Hop Options header 95 (HBH) is that the node will directly send the IPv6 packets with the 96 Hop-by-Hop Options header to the slow path (i.e. the control plane) 97 of the node. The option type of each option carried within the Hop- 98 by-Hop Options header will not even be examined before the packet is 99 sent to the slow path. Very often, such processing behavior is the 100 default configuration or, even worse, is the only behavior of the 101 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 DoS 105 attack on the router control plane and inconsistent packet drops due 106 to rate limiting on the interface between the router control plane 107 and forwarding plane, which will impact the normal end-to-end IP 108 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 functionalities. 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-limit mechanism is always implemented on the 184 same interface. However, such rate limiting mechanism will always 185 cause inconsistent packet drops, which will impact the normal IP 186 forwarding. 188 3. Specification of RFC8200 190 [RFC8200] defines several IPv6 extension header types, including the 191 Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- 192 by-Hop (HBH) Options header is used to carry optional information 193 that will be examined and processed by every node along a packet's 194 delivery path, and it is identified by a Next Header value of zero in 195 the IPv6 header. 197 The Hop-by-Hop (HBH) Options header contains the following fields: 199 -- Next Header: 8-bit selector, identifies the type of header 200 immediately following the Hop-by-Hop Options header. 202 -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 203 Options header in 8-octet units, not including the first 8 octets. 205 -- Options: Variable-length field, of length such that the complete 206 Hop-by-Hop Options header is an integer multiple of 8 octets long. 208 The Hop-by-Hop (HBH) Options header carries a variable number of 209 "options" that are encoded in the format of type-length-value (TLV). 211 The highest-order two bits (i.e., the ACT bits) of the Option Type 212 specify the action that must be taken if the processing IPv6 node 213 does not recognize the Option Type. The third-highest-order bit 214 (i.e., the CHG bit) of the Option Type specifies whether or not the 215 Option Data of that option can change en route to the packet's final 216 destination. 218 While [RFC2460] required that all nodes must examine and process the 219 Hop-by-Hop Options header, with [RFC8200] it is expected that nodes 220 along a packet's delivery path only examine and process the Hop-by- 221 Hop Options header if explicitly configured to do so. It means that 222 the HBH processing behavior in a node depends on the configuration on 223 it. 225 However, in the current [RFC8200], there is no explicit specification 226 on the possible configurations. Therefore, the nodes may be 227 configured to ignore the Hop-by-Hop Options header, drop packets 228 containing a Hop-by-Hop Options header, or assign packets containing 229 a Hop-by-Hop Options header to a slow processing path [RFC8200]. 230 Because of these likely uncertain processing behaviors, new hop-by- 231 hop options are not recommended. 233 4. Common Implementations 235 In the current common implementations, once an IPv6 packet, with its 236 Next Header field set to 0, arrives at a node, it will be directly 237 sent to the slow path (i.e. the control plane) of the node. With 238 such implementation, the value of the Next Header field in the IPv6 239 header is the only trigger for the default processing behavior. The 240 option type of each option carried within the Hop-by-Hop Options 241 header will not even be examined before the packet is sent to the 242 slow path. 244 Very often, such processing behavior is the default configuration on 245 the node, which is embedded in the implementation and cannot be 246 changed or reconfigured. 248 4.1. Historical Reasons 250 When IPv6 was first implemented on high-speed routers, HBH options 251 were not yet well-understood and ASICs were not so capable as they 252 are today. So, early IPv6 implementations dispatched all packets 253 that contain HBH options to their slow path. 255 4.2. Consequences 257 Such implementation introduces a risk of a DoS attack on the control 258 plane of the node, and a large flow of IPv6 packets could congest the 259 slow path, causing other critical functions (incl. routing and 260 network management) that are executed on the control plane to fail. 261 Rate limiting mechanisms will cause inconsistent packet drops and 262 impact the normal end-to-end IP forwarding of the network services. 264 5. Operators' typical processing 266 To mitigate this DoS vulnerability, many operators deployed Access 267 Control Lists (ACLs) that discard all packets containing HBH Options. 269 [RFC6564] shows the Reports from the field indicating that some IP 270 routers deployed within the global Internet are configured either to 271 ignore or to drop packets having a hop-by-hop header. As stated in 272 [RFC7872], many network operators perceive HBH Options to be a breach 273 of the separation between the forwarding and control planes. 274 Therefore, several network operators configured their nodes so to 275 discard all packets containing the HBH Options Extension Header, 276 while others configured nodes to forward the packet but to ignore the 277 HBH Options. [RFC7045] also states that hop-by-hop options are not 278 handled by many high-speed routers or are processed only on a slow 279 path. 281 Due to such behaviors observed and described in these specifications, 282 new hop-by-hop options are not recommended in [RFC8200] hence the 283 usability of HBH options is severely limited. 285 6. New Services 287 As IPv6 is being rapidly and widely deployed worldwide, more and more 288 applications and network services are migrating to or directly 289 adopting IPv6. More and more new services that require HBH are 290 emerging and the HBH Options header is going to be utilized by the 291 new services in various scenarios. 293 In-situ OAM with IPv6 encapsulation [I-D.ietf-ippm-ioam-ipv6-options] 294 is one of the examples. IOAM in IPv6 is used to enhance diagnostics 295 of IPv6 networks and complements other mechanisms, such as the IPv6 296 Performance and Diagnostic Metrics Destination Option described in 297 [RFC8250]. The IOAM data fields are encapsulated in "option data" 298 fields of the Hop-by-Hop Options header if Pre-allocated Tracing 299 Option, Incremental Tracing Option, or Proof of Transit Option are 300 carried [I-D.ietf-ippm-ioam-data], that is, the IOAM performs per 301 hop. 303 Alternate Marking Method can be used as the passive performance 304 measurement tool in an IPv6 domain. The AltMark Option is defined as 305 a new IPv6 extension header option to encode alternate marking 306 technique and Hop-by-Hop Options Header is considered 307 [I-D.ietf-6man-ipv6-alt-mark]. 309 The Minimum Path MTU Hop-by-Hop Option is defined in 310 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 311 forward path between a source host to a destination host. This Hop- 312 by-Hop option is intended to be used in environments like Data 313 Centers and on paths between Data Centers as well as other 314 environments including the general Internet. It provides a useful 315 tool for allowing to better take advantage of paths able to support a 316 large Path MTU. 318 As more services start utilizing the HBH Options header, more packets 319 containing HBH Options are going to be injected into the networks. 320 According to the current common configuration in most network 321 deployments, all the packets of the new services are going to be sent 322 to the control plane of the nodes, with the possible consequence of 323 causing a DoS effect on the control plane. The packets will be 324 dropped and the normal IP forwarding may be severely impacted. The 325 deployment of new network services involving multi-vendor 326 interoperability will become impossible. 328 7. The desired processing behavior 330 The following requirements should be met: 332 o The control plane SHOULD be protected from undesired traffic. 334 -* The HBH options header should not be directly sent to the control 335 plane once the packets are received since these options may not aim 336 for the control plane. 338 -* The HBH options that are not supposed to be processed by the 339 control plane should not be sent to the control plane, potentially 340 causing the DoS attack. 342 o Since generally the two types of HBH options (control plane and 343 forwarding plane) serve different purposes and require different 344 processing procedures on a node, they should be encoded separately 345 and carried in different packets. 347 o The packets carrying the HBH Forwarding Options are supposed to be 348 maintained in the forwarding plane rather than being directly sent 349 up to the control plane. While the packets carrying the HBH 350 Control Options are supposed to be sent to the control plane. 352 o The options aimed for the control plane are better not to consume 353 the forwarding plane resources. 355 o A simple and efficient way to discriminate the two types of HBH 356 options is required. 358 o The new deployments should be compatible with the existing 359 deployments, since default configuration of some devices running 360 in the networks cannot be changed or reconfigured. The update of 361 the networks in operation will usually take time. 363 o If the IPv6 extension header including the HBH options header of a 364 packet cannot be recognized by the node, or the option in the HBH 365 header is unknown to the node, and the node is not the destination 366 of the packet, the packet should not be dropped or sent to the 367 control plane, rather this unrecognized extension header should be 368 skipped and the rest of the packet should be processed. 370 8. Migration strategies 372 In order to achieve the desired processing behavior of the HBH 373 options header and facilitate the ever-emerging new services to be 374 deployed in operators' networks across multiple vendors' devices, the 375 migration can happen in three parts as described below: 377 1. The source of the HBH options header encapsulation. 379 The information to be carried in the HBH options header needs to be 380 first categorized and encapsulated into either control options or 381 forwarding options, and then encapsulated in different packets. 383 2. The nodes within the network. 385 The nodes are updated to the proposed behavior introduced in the 386 previous section. 388 3. The edge node of the network. 390 The edge node should check whether the packet contains a HBH header 391 with control or forwarding option. Packet with a control option may 392 still be filtered and dropped while packets with forwarding option 393 should be allowed by the ACL. 395 If it is certain that there is no harm that can be introduced by the 396 HBH options to the nodes and the services, they can also be allowed. 398 Note: During the migration stage, the nodes that are not yet updated 399 will stay with their existing configurations. 401 9. Security Considerations 403 It is the same as the Security Considerations in [RFC8200] for the 404 part related with the HBH Options header. 406 10. IANA Considerations 408 This document does not include an IANA request. 410 11. Acknowledgements 412 The authors would like to acknowledge Ron Bonica and Stefano Previdi 413 for their valuable review and comments. 415 12. References 417 12.1. Normative References 419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 420 Requirement Levels", BCP 14, RFC 2119, 421 DOI 10.17487/RFC2119, March 1997, 422 . 424 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 425 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 426 December 1998, . 428 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 429 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 430 March 2011, . 432 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 433 of IPv6 Extension Headers", RFC 7045, 434 DOI 10.17487/RFC7045, December 2013, 435 . 437 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 438 "Observations on the Dropping of Packets with IPv6 439 Extension Headers in the Real World", RFC 7872, 440 DOI 10.17487/RFC7872, June 2016, 441 . 443 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 444 (IPv6) Specification", STD 86, RFC 8200, 445 DOI 10.17487/RFC8200, July 2017, 446 . 448 12.2. Informative References 450 [I-D.ietf-6man-ipv6-alt-mark] 451 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 452 Pang, "IPv6 Application of the Alternate Marking Method", 453 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 454 October 2020. 456 [I-D.ietf-6man-mtu-option] 457 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 458 by-Hop Option", draft-ietf-6man-mtu-option-04 (work in 459 progress), October 2020. 461 [I-D.ietf-ippm-ioam-data] 462 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 463 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 464 progress), November 2020. 466 [I-D.ietf-ippm-ioam-ipv6-options] 467 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 468 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 469 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 470 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 471 ipv6-options-04 (work in progress), November 2020. 473 [I-D.li-6man-hbh-fwd-hdr] 474 Li, Z. and S. Peng, "Hop-by-Hop Forwarding Options 475 Header", draft-li-6man-hbh-fwd-hdr-00 (work in progress), 476 July 2020. 478 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 479 Performance and Diagnostic Metrics (PDM) Destination 480 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 481 . 483 Authors' Addresses 485 Shuping Peng 486 Huawei Technologies 487 Beijing 488 China 490 Email: pengshuping@huawei.com 492 Zhenbin Li 493 Huawei Technologies 494 Beijing 495 China 497 Email: lizhenbin@huawei.com 499 Chongfeng Xie 500 China Telecom 501 China 503 Email: xiechf@chinatelecom.cn 505 Zhuangzhuang Qin 506 China Unicom 507 Beijing 508 China 510 Email: qinzhuangzhuang@chinaunicom.cn 512 Gyan Mishra 513 Verizon Inc. 514 USA 516 Email: gyan.s.mishra@verizon.com