idnits 2.17.1 draft-li-6man-hbh-fwd-hdr-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2021) is 1155 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6564' is mentioned on line 101, but not defined == Missing Reference: 'RFC2460' is mentioned on line 166, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'RFC8250' is mentioned on line 284, but not defined == Missing Reference: 'I-D.ietf-ippm-ioam-data' is mentioned on line 287, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7872 == 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 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: August 24, 2021 G. Mishra 6 Verizon Inc. 7 February 20, 2021 9 Hop-by-Hop Forwarding Options Header 10 draft-li-6man-hbh-fwd-hdr-01 12 Abstract 14 RFC8200 specifies the HBH header that is assumed to be processed by 15 each hop in the delivery path of the packet. However, RFC8200 also 16 expects that nodes processing the HBH header have been explicitly 17 configured to do so. Therefore, it cannot be assumed that a HBH 18 header present in the packet is processed. It all depends on the 19 configuration of each node across the path. Moreover, in most of 20 networks today, the processing of the HBH header is done in the 21 control plane (slow processing path) which incurs several limitations 22 among which resources consumption and security risk. 24 For these reasons, over time, the Hop-by-Hop Options header has been 25 sparsely used without any form of large scale deployment. Also, most 26 of already defined HBH options are forwarding options which contain 27 forwarding plane information that needs not to be sent to the control 28 plane. 30 This document proposes a new Hop-by-Hop Forwarding Options Header in 31 order to carry Hop-by-Hop options that are solely intended to and 32 processed by the forwarding plane. This new HBH header is confined 33 in and dedicated to the forwarding plane while the current HBH header 34 can still be used for control plane options. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 24, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 77 2. Problem Statement and Motivation . . . . . . . . . . . . . . 4 78 2.1. Specifications in RFC8200 . . . . . . . . . . . . . . . . 4 79 2.2. Classification of HBH Options . . . . . . . . . . . . . . 5 80 2.3. Service Requirements . . . . . . . . . . . . . . . . . . 6 81 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 3.1. Hop-by-Hop Forwarding Options Header . . . . . . . . . . 7 83 3.2. The usage of the existing Hop-by-Hop Options Header . . . 8 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 6. Appendix. Existing HBH Options . . . . . . . . . . . . . . . 8 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 89 7.2. Informative References . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 92 1. Introduction 94 As specified in [RFC8200], the Hop-by-Hop (HBH) Options header is 95 used to carry optional information that will be examined and 96 processed by every node along a packet's delivery path if it is 97 explicitly configured to do so. Since there is no specification on 98 the possible configuration, nodes may be configured to ignore the 99 Hop-by-Hop Options header, drop packets containing a Hop-by-Hop 100 Options header, or assign packets containing a Hop-by-Hop Options 101 header to a slow processing path. [RFC6564] shows the Reports from 102 the field indicating that some IP routers deployed within the global 103 Internet are configured either to ignore or to drop packets having a 104 hop-by-hop header. As stated in [RFC7872], many network operators 105 perceive HBH Options to be a breach of the separation between the 106 forwarding and control planes. Therefore, several network operators 107 configured their nodes so to discard all packets containing the HBH 108 Options Extension Header, while others configured nodes to forward 109 the packet but to ignore the HBH Options. [RFC7045] also states that 110 hop-by-hop options are not handled by many high-speed routers or are 111 processed only on a slow path. 113 Generally, modern routers maintain the separation between forwarding 114 plane and control plane with plentiful forwarding plane resource but 115 constrained control plane resource. In order to protect the control 116 plane, policies are enforced in order to restrict access from the 117 forwarding plane to the control plane. Some operators severely rate- 118 limit packets containing the HBH Options Extension Header when they 119 are being sent to the control plane which will cause packet drops. 121 The Hop-by-Hop Options can be categorized into Hop-by-Hop Forwarding 122 Options and Hop-by-Hop Control Options, which contains information 123 for the forwarding plane and the control plane of the nodes, 124 respectively. It is necessary and required to separate the two types 125 of Hop-by-Hop options since they require different process 126 procedures. The packets carrying the Hop-by-Hop Forwarding Options 127 are supposed to be maintained in the forwarding plane while the 128 packets carrying the Hop-by-Hop Control Options are supposed to be 129 sent to the control plane. The current Hop-by-Hop Options header 130 specified in [RFC8200] is used to carry both types of Hop-by-Hop 131 options, and there is no way or indicator to separate the processing 132 of the two kinds of Hop-by-Hop options using the current 133 specifications in [RFC8200]. 135 In the current networks, the common implementation is to send all 136 packets containing a HBH header to the control plane even if they 137 contain only pad options (a forwarding option specified in 138 [RFC8200]), resulting in various possible effects such as a risk of a 139 DoS attack on the router, inconsistent drops among those packets due 140 to rate limiting, or other effects. This will impact the normal end- 141 to-end IP forwarding of the network services. 143 Therefore, due to these limitations, the HBH header has seen limited 144 use and deployments, and protocol designers are recommended to avoid 145 using hop-by-hop options in any new protocols. However, there have 146 been over ten HBH options already specified in RFCs as listed in 147 Appendix and the specified Forwarding Options are in the majority. 148 Moreover, as IPv6 is being rapidly and widely deployed worldwide, 149 more and more new services that requires hop-by-hop forwarding 150 process behavior are emerging such as IOAM with IPv6 encapsulation 151 [draft-ietf-ippm-ioam-ipv6-options]. Therefore, these requirements 152 should be addressed urgently and properly by the use of an efficient 153 HBH header when processed in the forwarding plane by transit nodes. 155 This document proposes a Hop-by-Hop Forwarding Options header to 156 carry the Hop-by-Hop forwarding options while the existing Hop-by-Hop 157 Options header is used to carry the Hop-by-Hop control options only. 159 2. Problem Statement and Motivation 161 This section describes the problem statement and motivation for 162 defining a new Hop-by-Hop Forwarding Options header. 164 2.1. Specifications in RFC8200 166 While [RFC2460] required that all nodes must examine and process the 167 Hop-by-Hop Options header, with [RFC8200] it is expected that nodes 168 along a packet's delivery path only examine and process the Hop-by- 169 Hop Options header if explicitly configured to do so. The 170 configuration of the node determines the HBH processing behavior in 171 the node which implies that each node may have a different behavior 172 than the others. As specified in [RFC8200], nodes may be configured 173 to ignore the Hop-by-Hop Options header or drop packets containing a 174 Hop-by-Hop Options header or assign packets containing a Hop-by-Hop 175 Options header to a slow processing path. These various behaviors 176 are observed and described in specifications such as [RFC7045] and 177 [RFC7872]. Due to such behaviors, new hop-by-hop options are not 178 recommended in [RFC8200] hence the usability of HBH options is 179 severely limited. 181 The Hop-by-Hop Options header is identified by a Next Header value of 182 zero in the IPv6 header. Currently, the behaviors performed by the 183 nodes on the packets containing a Hop-by-Hop Options header is only 184 based on the value of this Next Header in the IPv6 header, that is, 185 the value of the Next Header is the only trigger for the behaviors to 186 be performed. 188 In current networks, usually, nodes are configured in order to assign 189 packets containing a Hop-by-Hop Options header (indicated by the Next 190 Header = 0) to a slow processing path, i.e. to the control plane of 191 the nodes. Very often, such configuration is embedded in the 192 implementation of the node and cannot be changed or reconfigured. 194 2.2. Classification of HBH Options 196 The Hop-by-Hop Options header contains one or more Hop-by-Hop 197 Options. Each HBH Option contains a type identifier, i.e. Option 198 Type. The Hop-by-Hop Options can be categorized into two types: HBH 199 Forwarding Options and HBH Control Options. The HBH forward options 200 contain information that is useful to a router's forwarding plane, 201 e.g. the Jumbo Payload Option [RFC2675]. While the HBH Control 202 Options contain information that is useful to a router's control 203 plane, e.g. the Router Alert Option [RFC2711]. Currently, both HBH 204 forwarding and control options are carried in the same HBH Options 205 header. There is no specification defining rules for differentiating 206 the process of the two kinds of options. 208 According to the common configuration in the current networks, i.e. 209 to assign packets containing a Hop-by-Hop Options header (indicated 210 by the Next Header = 0) to a slow processing path, all the HBH 211 Options will be sent to the control plane of the nodes. It impacts 212 the normal IP forwarding procedure of the packets containing the HBH 213 forwarding options which should be processed in the forwarding plane. 214 As stated above, it also introduces a severe risk of DoS attacks 215 using HBH headers. 217 If all the HBH Options are forced to be processed first in the 218 forwarding plane and then classified according to the HBH Option 219 Type, it requires the consumption of the forwarding plane resources 220 to make such processing selection, which will impact the forwarding 221 efficiency. Moreover, there are some existing nodes that are 222 configured to assign the packets containing a Hop-by-Hop Options 223 header to the control plane of the nodes cannot be reconfigured. 225 Appendix of this document provides the classification of the 226 currently defined HBH options into HBH forwarding options and HBH 227 control options, and the HBH forwarding options are in the majority. 229 IPv6 Extended Header limitations that need to be addressed to make 230 HBH processing more efficient and viable in the fast path: 232 [RFC8504] defines the IPv6 node requirements and how to protect a 233 node from excessive header chain and excessive header options with 234 various limitations that can be defined on a node. [RFC8883] defines 235 ICMPv6 Errors for discarding packets due to processing limits. Per 236 [RFC8200] HBH options must be processed serially. However, an 237 implementation of options processing can be made to be done with more 238 parallelism in serial processing grouping of similar options to be 239 processed in parallel. 241 The IPv6 standard does not currently limit the header chain length or 242 number of options that can be encoded. 244 Each Option is encoded in a TLV and so processing of a long list of 245 TLVs is expensive. Zero data length encoded options TLVs are a valid 246 option. A DOS vector could be easily generated by encoding 1000 HBH 247 options (Zero data length) in a standard 1500 MTU packet. So now 248 Imagine if you have a Christmas tree long header chain to parse each 249 with many options. 251 Limit length of the header chain. 253 Reduce the length of the HBH which is currently 2,048 bytes. 255 Limit the maximum number of HBH. 257 Limit the maximum number of options in an HBH. 259 2.3. Service Requirements 261 As listed in the Appendix, there have been over ten HBH options 262 already specified in RFCs and the specified forwarding options are in 263 the majority. As IPv6 is being rapidly and widely deployed 264 worldwide, more and more applications and network services are 265 migrating to or adopting IPv6. More and more new services that 266 requires hop-by-hop forwarding process behavior are emerging and the 267 HBH Options header is going to be utilized by new services in various 268 use scenarios. 270 As more services start utilizing the HBH Options header, more packets 271 containing HBH Options are going to be injected into the networks. 272 According to the current common configuration in most network 273 deployments, all the packets of the new services are going to be sent 274 to the control plane of the nodes, with the possible consequence of 275 causing a DoS effect on the control plane. The packets will be 276 dropped and the normal IP forwarding may be severely impacted. The 277 deployment of new network services involving multi-vendor 278 interoperability will become impossible. 280 In-situ OAM with IPv6 encapsulation [draft-ietf-ippm-ioam- 281 ipv6-options] is one of the examples. IOAM in IPv6 is used to 282 enhance diagnostics of IPv6 networks and complements other 283 mechanisms, such as the IPv6 Performance and Diagnostic Metrics 284 Destination Option described in [RFC8250]. The IOAM data fields are 285 encapsulated in "option data" fields of the Hop-by-Hop Options header 286 if Pre-allocated Tracing Option, Incremental Tracing Option, or Proof 287 of Transit Option are carried [I-D.ietf-ippm-ioam-data], that is, the 288 IOAM performs per hop. 290 As above mentioned, according to the current common configuration, 291 all the packets employing IOAM are going to be sent to the control 292 plane of every node along the path, it will cause a severe effect DoS 293 on the control plane. The packets will be inconsistently dropped and 294 the normal IP forwarding will be severely impacted. The end-to-end 295 deployment of IOAM in a network involving nodes from multiple vendors 296 is impossible. 298 3. Proposal 300 3.1. Hop-by-Hop Forwarding Options Header 302 We propose to define a new HBH Forwarding Options header dedicated to 303 carry the HBH Forwarding Options. The IPv6 packets containing this 304 Hop-by-Hop Forwarding Options header will be only processed in the 305 forwarding plane and MUST NOT be sent to the control plane of the 306 network nodes. 308 The Hop-by-Hop Forwarding Options header is identified by a Next 309 Header value of TBD in the IPv6 header and has the following format: 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Next Header | Hdr Ext Len | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 314 | | 315 . . 316 . HBH Forwarding Options . 317 . . 318 | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Next Header 8-bit selector. Identifies the type of header 322 immediately following the Hop-by-Hop 323 Forwarding Options header. 325 Hdr Ext Len 8-bit unsigned integer. Length of the 326 Hop-by-Hop Forwarding Options header in 8-octet 327 units, not including the first 8 octets. 329 Options Variable-length field, of length such that the 330 complete Hop-by-Hop Options header is an 331 integer multiple of 8 octets long. Contains 332 one or more TLV-encoded HBH forwarding options. 334 The Hop-by-Hop Forwarding Options header is recommended to be placed 335 immediately after the IPv6 header. 337 The Hop-by-Hop Forwarding Options follows the formatting guidelines 338 specified in the Appendix A. of [RFC8200]. 340 3.2. The usage of the existing Hop-by-Hop Options Header 342 The existing Hop-by-Hop Options Header, identified by a Next Header 343 value of zero in the IPv6 header, can still be used for carrying the 344 HBH control options. The IPv6 packets carrying such HBH control 345 options will be sent to the control plane anyway, so it follows the 346 exact current processing procedures. 348 4. Security Considerations 350 It is the same as the Security Considerations in [RFC8200] for the 351 part related with the HBH Options header. 353 5. IANA Considerations 355 TBD: Next Header for Hop-by-Hop Forwarding Options Header 357 6. Appendix. Existing HBH Options 359 We further classify the HBH Options into HBH Forwarding and HBH 360 Control Options. We can see that among all the defined HBH Options 361 the HBH Forwarding Options are in the majority. 363 HBH Forwarding Options: 365 o PAD Options: PAD1 and PADn [RFC8200] 367 o Jumbo Payload [RFC2675] 369 o RPL Option [RFC6553] 371 o Common Architecture Label 1Pv6 Security Option [RFC5570] 373 o SMF Option [RFC6621] 375 o MPL Option [RFC7731] 377 o DFF Option [RFC6971] 379 o MTU Option [I-D.ietf-6man-mtu-option] 381 o AltMark Option [I-D.ietf-6man-ipv6-alt-mark] 383 HBH Control Options: 385 o Router Alert Option [RFC2711] 387 o Quickstart Option [RFC4782] 389 7. References 391 7.1. Normative References 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, 395 DOI 10.17487/RFC2119, March 1997, 396 . 398 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 399 of IPv6 Extension Headers", RFC 7045, 400 DOI 10.17487/RFC7045, December 2013, 401 . 403 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 404 "Observations on the Dropping of Packets with IPv6 405 Extension Headers in the Real World", RFC 7872, 406 DOI 10.17487/RFC7872, June 2016, 407 . 409 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 410 (IPv6) Specification", STD 86, RFC 8200, 411 DOI 10.17487/RFC8200, July 2017, 412 . 414 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node 415 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, 416 January 2019, . 418 [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to 419 Processing Limits", RFC 8883, DOI 10.17487/RFC8883, 420 September 2020, . 422 7.2. Informative References 424 [I-D.ietf-6man-ipv6-alt-mark] 425 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 426 Pang, "IPv6 Application of the Alternate Marking Method", 427 draft-ietf-6man-ipv6-alt-mark-02 (work in progress), 428 October 2020. 430 [I-D.ietf-6man-mtu-option] 431 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 432 by-Hop Option", draft-ietf-6man-mtu-option-04 (work in 433 progress), October 2020. 435 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 436 RFC 2675, DOI 10.17487/RFC2675, August 1999, 437 . 439 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 440 RFC 2711, DOI 10.17487/RFC2711, October 1999, 441 . 443 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 444 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 445 January 2007, . 447 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 448 Architecture Label IPv6 Security Option (CALIPSO)", 449 RFC 5570, DOI 10.17487/RFC5570, July 2009, 450 . 452 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 453 Power and Lossy Networks (RPL) Option for Carrying RPL 454 Information in Data-Plane Datagrams", RFC 6553, 455 DOI 10.17487/RFC6553, March 2012, 456 . 458 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 459 RFC 6621, DOI 10.17487/RFC6621, May 2012, 460 . 462 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 463 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 464 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 465 . 467 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 468 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 469 February 2016, . 471 Authors' Addresses 473 Zhenbin Li 474 Huawei Technologies 476 Email: lizhenbin@huawei.com 477 Shuping Peng 478 Huawei Technologies 480 Email: pengshuping@huawei.com 482 Gyan Mishra 483 Verizon Inc. 485 Email: gyan.s.mishra@verizon.com