idnits 2.17.1 draft-peng-v6ops-hbh-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2020) is 1280 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6564' is mentioned on line 265, 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-01 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-03 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-03 == 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: April 27, 2021 C. Xie 6 China Telecom 7 Z. Qin 8 China Unicom 9 October 24, 2020 11 Processing of the Hop-by-Hop Options Header 12 draft-peng-v6ops-hbh-01 14 Abstract 16 This document describes the processing of the Hop-by-Hop Options 17 Header in today's routers in the aspects of standards specification, 18 common implementations, and default operations. This document 19 outlines the reasons why the Hop-by-Hop Options Header is rarely 20 utilized in current networks. In addition, this document describes 21 why the HBH could be used as a powerful mechanism allowing deployment 22 and operations of new services requiring a more optimized way to 23 leverage network resources of an infrastructure. The Hop-by-Hop 24 Options Header is taken into consideration as a valuable container 25 for carrying the information facilitating the introduction of new 26 services. The desired, and proposed, processing behavior of the HBH 27 and the migration strategies towards it are also suggested. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 27, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Modern Router Architecture . . . . . . . . . . . . . . . . . 3 70 3. Specification of RFC8200 . . . . . . . . . . . . . . . . . . 4 71 4. Common Implementations . . . . . . . . . . . . . . . . . . . 5 72 4.1. Historical Reasons . . . . . . . . . . . . . . . . . . . 6 73 4.2. Consequences . . . . . . . . . . . . . . . . . . . . . . 6 74 5. Operators' typical processing . . . . . . . . . . . . . . . . 6 75 6. New Services . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. The desired processing behavior . . . . . . . . . . . . . . . 7 77 8. Migration strategies . . . . . . . . . . . . . . . . . . . . 8 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 12.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 Due to the historical reasons, such as incapable ASICs, limited IPv6 89 deployments and few service requirements, the current common 90 implementation on the processing of the Hop-by-Hop Options header 91 (HBH) is that the node will directly send the IPv6 packets with the 92 Hop-by-Hop Options header to the slow path (i.e. the control plane) 93 of the node. The option type of each option carried within the Hop- 94 by-Hop Options header will not even be examined before the packet is 95 sent to the slow path. Very often, such processing behavior is the 96 default configuration or, even worse, is the only behavior of the 97 ipv6 implementation of the node. 99 Such default processing behavior of the Hop-by-Hop Options header 100 could result in various unpleasant effects such as a risk of DoS 101 attack on the router control plane and inconsistent packet drops due 102 to rate limiting on the interface between the router control plane 103 and forwarding plane, which will impact the normal end-to-end IP 104 forwarding of the network services. 106 This actually introduced a circular problem: 108 -> An implementation problem caused HBH to become a DoS vector. 110 -> Because HBH is a DoS vector, network operators deployed ACLs that 111 discard packets containing HBH. 113 -> Because network operators deployed ACLs that discard packets 114 containing HBH, network designers stopped defining new HBH Options. 116 -> Because network designers stopped defining new HBH Options, the 117 community was not motivated to fix the implementation problem that 118 cause HBH to become a DoS vector. 120 The purpose of this draft is to break the cycle described above, 121 fixing the problem that caused HBH not actually being utilized in 122 operators' networks so to allow a better leverage of the HBH 123 capability. 125 Driven by the wide deployments of IPv6 and ever-emerging new 126 services, the Hop-by-Hop Options Header is taken as a valuable 127 container for carrying the information to facilitate these new 128 services. 130 This document suggests the desired processing behavior and the 131 migration strategies towards it. 133 2. Modern Router Architecture 135 Modern router architecture design maintains a strict separation of 136 the router control plane and its forwarding plane [RFC6192], as shown 137 in Figure 1. Either the control plane or the forwarding plane is 138 composed of both software and hardware, but each plane is responsible 139 for different functionalities. 141 +----------------+ 142 | Router Control | 143 | Plane | 144 +------+-+-------+ 145 | | 146 Interface Z 147 | | 148 +------+-+-------+ 149 | Forwarding | 150 Interface X ==[ Plane ]== Interface Y 151 +----------------+ 153 Figure 1. Modern Router Architecture 155 The router control plane supports routing and management functions, 156 handling packets destined to the device as well as building and 157 sending packets originated locally on the device, and also drives the 158 programming of the forwarding plane. The router control plane is 159 generally realized in software on general-purpose processors, and its 160 hardware is usually not optimized for high-speed packet handling. 161 Because of the wide range of functionality, it is more susceptible to 162 security vulnerabilities and a more likely a target for a DoS attack. 164 The forwarding plane is typically responsible for receiving a packet 165 on an incoming interface, performing a lookup to identify the 166 packet's next hop and determine the outgoing interface towards the 167 destination, and forwarding the packet out through the appropriate 168 outgoing interface. Typically, forwarding plane functionality is 169 realized in high-performance Application Specific Integrated Circuits 170 (ASICs) or Network Processors (NPs) that are capable of handling very 171 high packet rates. 173 The router control plane interfaces with its forwarding plane through 174 the Interface Z, as shown in the Figure 1, and the forwarding plane 175 connects to other network devices via Interfaces such as X and Y. 176 Since the router control plane is vulnerable to the DoS attack, 177 usually a traffic filtering mechanism is implemented on Interface Z 178 in order to block unwanted traffic. In order to protect the router 179 control plane, a rate-limit mechanism is always implemented on the 180 same interface. However, such rate limiting mechanism will always 181 cause inconsistent packet drops, which will impact the normal IP 182 forwarding. 184 3. Specification of RFC8200 186 [RFC8200] defines several IPv6 extension header types, including the 187 Hop-by-Hop (HBH) Options header. As specified in [RFC8200], the Hop- 188 by-Hop (HBH) Options header is used to carry optional information 189 that will be examined and processed by every node along a packet's 190 delivery path, and it is identified by a Next Header value of zero in 191 the IPv6 header. 193 The Hop-by-Hop (HBH) Options header contains the following fields: 195 -- Next Header: 8-bit selector, identifies the type of header 196 immediately following the Hop-by-Hop Options header. 198 -- Hdr Ext Len: 8-bit unsigned integer, the length of the Hop-by-Hop 199 Options header in 8-octet units, not including the first 8 octets. 201 -- Options: Variable-length field, of length such that the complete 202 Hop-by-Hop Options header is an integer multiple of 8 octets long. 204 The Hop-by-Hop (HBH) Options header carries a variable number of 205 "options" that are encoded in the format of type-length-value (TLV). 207 The highest-order two bits (i.e., the ACT bits) of the Option Type 208 specify the action that must be taken if the processing IPv6 node 209 does not recognize the Option Type. The third-highest-order bit 210 (i.e., the CHG bit) of the Option Type specifies whether or not the 211 Option Data of that option can change en route to the packet's final 212 destination. 214 While [RFC2460] required that all nodes must examine and process the 215 Hop-by-Hop Options header, with [RFC8200] it is expected that nodes 216 along a packet's delivery path only examine and process the Hop-by- 217 Hop Options header if explicitly configured to do so. It means that 218 the HBH processing behavior in a node depends on the configuration on 219 it. 221 However, in the current [RFC8200], there is no explicit specification 222 on the possible configurations. Therefore, the nodes may be 223 configured to ignore the Hop-by-Hop Options header, drop packets 224 containing a Hop-by-Hop Options header, or assign packets containing 225 a Hop-by-Hop Options header to a slow processing path [RFC8200]. 226 Because of these likely uncertain processing behaviors, new hop-by- 227 hop options are not recommended. 229 4. Common Implementations 231 In the current common implementations, once an IPv6 packet, with its 232 Next Header field set to 0, arrives at a node, it will be directly 233 sent to the slow path (i.e. the control plane) of the node. With 234 such implementation, the value of the Next Header field in the IPv6 235 header is the only trigger for the default processing behavior. The 236 option type of each option carried within the Hop-by-Hop Options 237 header will not even be examined before the packet is sent to the 238 slow path. 240 Very often, such processing behavior is the default configuration on 241 the node, which is embedded in the implementation and cannot be 242 changed or reconfigured. 244 4.1. Historical Reasons 246 When IPv6 was first implemented on high-speed routers, HBH options 247 were not yet well-understood and ASICs were not so capable as they 248 are today. So, early IPv6 implementations dispatched all packets 249 that contain HBH options to their slow path. 251 4.2. Consequences 253 Such implementation introduces a risk of a DoS attack on the control 254 plane of the node, and a large flow of IPv6 packets could congest the 255 slow path, causing other critical functions (incl. routing and 256 network management) that are executed on the control plane to fail. 257 Rate limiting mechanisms will cause inconsistent packet drops and 258 impact the normal end-to-end IP forwarding of the network services. 260 5. Operators' typical processing 262 To mitigate this DoS vulnerability, many operators deployed Access 263 Control Lists (ACLs) that discard all packets containing HBH Options. 265 [RFC6564] shows the Reports from the field indicating that some IP 266 routers deployed within the global Internet are configured either to 267 ignore or to drop packets having a hop-by-hop header. As stated in 268 [RFC7872], many network operators perceive HBH Options to be a breach 269 of the separation between the forwarding and control planes. 270 Therefore, several network operators configured their nodes so to 271 discard all packets containing the HBH Options Extension Header, 272 while others configured nodes to forward the packet but to ignore the 273 HBH Options. [RFC7045] also states that hop-by-hop options are not 274 handled by many high-speed routers or are processed only on a slow 275 path. 277 Due to such behaviors observed and described in these specifications, 278 new hop-by-hop options are not recommended in [RFC8200] hence the 279 usability of HBH options is severely limited. 281 6. New Services 283 As IPv6 is being rapidly and widely deployed worldwide, more and more 284 applications and network services are migrating to or directly 285 adopting IPv6. More and more new services that require HBH are 286 emerging and the HBH Options header is going to be utilized by the 287 new services in various scenarios. 289 In-situ OAM with IPv6 encapsulation [I-D.ietf-ippm-ioam-ipv6-options] 290 is one of the examples. IOAM in IPv6 is used to enhance diagnostics 291 of IPv6 networks and complements other mechanisms, such as the IPv6 292 Performance and Diagnostic Metrics Destination Option described in 293 [RFC8250]. The IOAM data fields are encapsulated in "option data" 294 fields of the Hop-by-Hop Options header if Pre-allocated Tracing 295 Option, Incremental Tracing Option, or Proof of Transit Option are 296 carried [I-D.ietf-ippm-ioam-data], that is, the IOAM performs per 297 hop. 299 Alternate Marking Method can be used as the passive performance 300 measurement tool in an IPv6 domain. The AltMark Option is defined as 301 a new IPv6 extension header option to encode alternate marking 302 technique and Hop-by-Hop Options Header is considered 303 [I-D.ietf-6man-ipv6-alt-mark]. 305 The Minimum Path MTU Hop-by-Hop Option is defined in 306 [I-D.ietf-6man-mtu-option] to record the minimum Path MTU along the 307 forward path between a source host to a destination host. This Hop- 308 by-Hop option is intended to be used in environments like Data 309 Centers and on paths between Data Centers as well as other 310 environments including the general Internet. It provides a useful 311 tool for allowing to better take advantage of paths able to support a 312 large Path MTU. 314 As more services start utilizing the HBH Options header, more packets 315 containing HBH Options are going to be injected into the networks. 316 According to the current common configuration in most network 317 deployments, all the packets of the new services are going to be sent 318 to the control plane of the nodes, with the possible consequence of 319 causing a DoS effect on the control plane. The packets will be 320 dropped and the normal IP forwarding may be severely impacted. The 321 deployment of new network services involving multi-vendor 322 interoperability will become impossible. 324 7. The desired processing behavior 326 The HBH Options actually contain information for the use of the 327 forwarding plane and the control plane of the nodes, respectively. 329 They can be categorized into HBH Forwarding Options and HBH Control 330 Options [I-D.li-6man-hbh-fwd-hdr]. 332 It is suggested to separate the two types of HBH options and carry 333 them in different packets since generally they serve for different 334 purposes and require different processing procedures on a node. The 335 packets carrying the HBH Forwarding Options are supposed to be 336 maintained in the forwarding plane rather than being directly sent up 337 to the control plane. While the packets carrying the HBH Control 338 Options are supposed to be sent to the control plane. 340 If the IPv6 extension header including the HBH options header of a 341 packet cannot be recognized by the node, or the option in the HBH 342 header is unknown to the node, and the node is not the destination of 343 the packet, the packet should not be dropped or sent to the control 344 plane, rather this unrecognized extension header should be skipped 345 and the rest of the packet should be processed. 347 8. Migration strategies 349 In order to achieve the desired processing behavior of the HBH 350 options header and facilitate the ever-emerging new services to be 351 deployed in operators' networks across multiple vendors' devices, the 352 migration can happen in three parts as described below: 354 1. The source of the HBH options header encapsulation. 356 The information to be carried in the HBH options header needs to be 357 first categorized and encapsulated into either control options or 358 forwarding options, and then encapsulated in different packets. 360 2. The nodes within the network. 362 The nodes are updated to the proposed behavior introduced in the 363 previous section. 365 3. The edge node of the network. 367 The edge node should check whether the packet contains a HBH header 368 with control or forwarding option. Packet with a control option may 369 still be filtered and dropped while packets with forwarding option 370 should be allowed by the ACL. 372 If it is certain that there is no harm that can be introduced by the 373 HBH options to the nodes and the services, they can also be allowed. 375 Note: During the migration stage, the nodes that are not yet updated 376 will stay with their existing configurations. 378 9. Security Considerations 380 It is the same as the Security Considerations in [RFC8200] for the 381 part related with the HBH Options header. 383 10. IANA Considerations 385 This document does not include an IANA request. 387 11. Acknowledgements 389 The authors would like to acknowledge Ron Bonica and Stefano Previdi 390 for their valuable review and comments. 392 12. References 394 12.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 402 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 403 December 1998, . 405 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 406 Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, 407 March 2011, . 409 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 410 of IPv6 Extension Headers", RFC 7045, 411 DOI 10.17487/RFC7045, December 2013, 412 . 414 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 415 "Observations on the Dropping of Packets with IPv6 416 Extension Headers in the Real World", RFC 7872, 417 DOI 10.17487/RFC7872, June 2016, 418 . 420 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 421 (IPv6) Specification", STD 86, RFC 8200, 422 DOI 10.17487/RFC8200, July 2017, 423 . 425 12.2. Informative References 427 [I-D.ietf-6man-ipv6-alt-mark] 428 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 429 Pang, "IPv6 Application of the Alternate Marking Method", 430 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 431 2020. 433 [I-D.ietf-6man-mtu-option] 434 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 435 by-Hop Option", draft-ietf-6man-mtu-option-03 (work in 436 progress), September 2020. 438 [I-D.ietf-ippm-ioam-data] 439 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 440 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 441 progress), July 2020. 443 [I-D.ietf-ippm-ioam-ipv6-options] 444 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 445 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 446 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 447 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 448 ipv6-options-03 (work in progress), September 2020. 450 [I-D.li-6man-hbh-fwd-hdr] 451 Li, Z. and S. Peng, "Hop-by-Hop Forwarding Options 452 Header", draft-li-6man-hbh-fwd-hdr-00 (work in progress), 453 July 2020. 455 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 456 Performance and Diagnostic Metrics (PDM) Destination 457 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 458 . 460 Authors' Addresses 462 Shuping Peng 463 Huawei Technologies 464 Beijing 100095 465 China 467 Email: pengshuping@huawei.com 468 Zhenbin Li 469 Huawei Technologies 470 Beijing 100095 471 China 473 Email: lizhenbin@huawei.com 475 Chongfeng Xie 476 China Telecom 477 China 479 Email: xiechf@chinatelecom.cn 481 Zhuangzhuang Qin 482 China Unicom 483 Beijing 484 China 486 Email: qinzhuangzhuang@chinaunicom.cn