idnits 2.17.1 draft-li-6man-hbh-fwd-hdr-00.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 (July 3, 2020) is 1365 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 99, but not defined == Missing Reference: 'RFC2460' is mentioned on line 165, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'RFC8250' is mentioned on line 254, but not defined == Missing Reference: 'I-D.ietf-ippm-ioam-data' is mentioned on line 257, 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-01 == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-02 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 5 Expires: January 4, 2021 July 3, 2020 7 Hop-by-Hop Forwarding Options Header 8 draft-li-6man-hbh-fwd-hdr-00 10 Abstract 12 RFC8200 specifies the HBH header that is assumed to be processed by 13 each hop in the delivery path of the packet. However, RFC8200 also 14 expects that nodes processing the HBH header have been explicitly 15 configured to do so. Therefore, it cannot be assumed that a HBH 16 header present in the packet is processed. It all depends on the 17 configuration of each node across the path. Moreover, in most of 18 networks today, the processing of the HBH header is done in the 19 control plane (slow processing path) which incurs several limitations 20 among which resources consumption and security risk. 22 For these reasons, over time, the Hop-by-Hop Options header has been 23 sparsely used without any form of large scale deployment. Also, most 24 of already defined HBH options are forwarding options which contain 25 forwarding plane information that needs not to be sent to the control 26 plane. 28 This document proposes a new Hop-by-Hop Forwarding Options Header in 29 order to carry Hop-by-Hop options that are solely intended to and 30 processed by the forwarding plane. This new HBH header is confined 31 in and dedicated to the forwarding plane while the current HBH header 32 can still be used for control plane options. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 4, 2021. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Problem Statement and Motivation . . . . . . . . . . . . . . 4 76 2.1. Specifications in RFC8200 . . . . . . . . . . . . . . . . 4 77 2.2. Classification of HBH Options . . . . . . . . . . . . . . 5 78 2.3. Service Requirements . . . . . . . . . . . . . . . . . . 5 79 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.1. Hop-by-Hop Forwarding Options Header . . . . . . . . . . 6 81 3.2. The usage of the existing Hop-by-Hop Options Header . . . 7 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 6. Appendix. Existing HBH Options . . . . . . . . . . . . . . . 8 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 7.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 As specified in [RFC8200], the Hop-by-Hop (HBH) Options header is 93 used to carry optional information that will be examined and 94 processed by every node along a packet's delivery path if it is 95 explicitly configured to do so. Since there is no specification on 96 the possible configuration, nodes may be configured to ignore the 97 Hop-by-Hop Options header, drop packets containing a Hop-by-Hop 98 Options header, or assign packets containing a Hop-by-Hop Options 99 header to a slow processing path. [RFC6564] shows the Reports from 100 the field indicating that some IP routers deployed within the global 101 Internet are configured either to ignore or to drop packets having a 102 hop-by-hop header. As stated in [RFC7872], many network operators 103 perceive HBH Options to be a breach of the separation between the 104 forwarding and control planes. Therefore, several network operators 105 configured their nodes so to discard all packets containing the HBH 106 Options Extension Header, while others configured nodes to forward 107 the packet but to ignore the HBH Options. [RFC7045] also states that 108 hop-by-hop options are not handled by many high-speed routers or are 109 processed only on a slow path. 111 Generally, modern routers maintain the separation between forwarding 112 plane and control plane with plentiful forwarding plane resource but 113 constrained control plane resource. In order to protect the control 114 plane, policies are enforced in order to restrict access from the 115 forwarding plane to the control plane. Some operators severely rate- 116 limit packets containing the HBH Options Extension Header when they 117 are being sent to the control plane which will cause packet drops. 119 The Hop-by-Hop Options can be categorized into Hop-by-Hop Forwarding 120 Options and Hop-by-Hop Control Options, which contains information 121 for the forwarding plane and the control plane of the nodes, 122 respectively. It is necessary and required to separate the two types 123 of Hop-by-Hop options since they require different process 124 procedures. The packets carrying the Hop-by-Hop Forwarding Options 125 are supposed to be maintained in the forwarding plane while the 126 packets carrying the Hop-by-Hop Control Options are supposed to be 127 sent to the control plane. The current Hop-by-Hop Options header 128 specified in [RFC8200] is used to carry both types of Hop-by-Hop 129 options, and there is no way or indicator to separate the processing 130 of the two kinds of Hop-by-Hop options using the current 131 specifications in [RFC8200]. 133 In the current networks, the common implementation is to send all 134 packets containing a HBH header to the control plane even if they 135 contain only pad options (a forwarding option specified in 136 [RFC8200]), resulting in various possible effects such as a risk of a 137 DoS attack on the router, inconsistent drops among those packets due 138 to rate limiting, or other effects. This will impact the normal end- 139 to-end IP forwarding of the network services. 141 Therefore, due to these limitations, the HBH header has seen limited 142 use and deployments, and protocol designers are recommended to avoid 143 using hop-by-hop options in any new protocols. However, there have 144 been over ten HBH options already specified in RFCs as listed in 145 Appendix and the specified Forwarding Options are in the majority. 147 Moreover, as IPv6 is being rapidly and widely deployed worldwide, 148 more and more new services that requires hop-by-hop forwarding 149 process behavior are emerging such as IOAM with IPv6 encapsulation 150 [draft-ietf-ippm-ioam-ipv6-options]. Therefore, these requirements 151 should be addressed urgently and properly by the use of an efficient 152 HBH header when processed in the forwarding plane by transit nodes. 154 This document proposes a Hop-by-Hop Forwarding Options header to 155 carry the Hop-by-Hop forwarding options while the existing Hop-by-Hop 156 Options header is used to carry the Hop-by-Hop control options only. 158 2. Problem Statement and Motivation 160 This section describes the problem statement and motivation for 161 defining a new Hop-by-Hop Forwarding Options header. 163 2.1. Specifications in RFC8200 165 While [RFC2460] required that all nodes must examine and process the 166 Hop-by-Hop Options header, with [RFC8200] it is expected that nodes 167 along a packet's delivery path only examine and process the Hop-by- 168 Hop Options header if explicitly configured to do so. The 169 configuration of the node determines the HBH processing behavior in 170 the node which implies that each node may have a different behavior 171 than the others. As specified in [RFC8200], nodes may be configured 172 to ignore the Hop-by-Hop Options header or drop packets containing a 173 Hop-by-Hop Options header or assign packets containing a Hop-by-Hop 174 Options header to a slow processing path. These various behaviors 175 are observed and described in specifications such as [RFC7045] and 176 [RFC7872]. Due to such behaviors, new hop-by-hop options are not 177 recommended in [RFC8200] hence the usability of HBH options is 178 severely limited. 180 The Hop-by-Hop Options header is identified by a Next Header value of 181 zero in the IPv6 header. Currently, the behaviors performed by the 182 nodes on the packets containing a Hop-by-Hop Options header is only 183 based on the value of this Next Header in the IPv6 header, that is, 184 the value of the Next Header is the only trigger for the behaviors to 185 be performed. 187 In current networks, usually, nodes are configured in order to assign 188 packets containing a Hop-by-Hop Options header (indicated by the Next 189 Header = 0) to a slow processing path, i.e. to the control plane of 190 the nodes. Very often, such configuration is embedded in the 191 implementation of the node and cannot be changed or reconfigured. 193 2.2. Classification of HBH Options 195 The Hop-by-Hop Options header contains one or more Hop-by-Hop 196 Options. Each HBH Option contains a type identifier, i.e. Option 197 Type. The Hop-by-Hop Options can be categorized into two types: HBH 198 Forwarding Options and HBH Control Options. The HBH forward options 199 contain information that is useful to a router's forwarding plane, 200 e.g. the Jumbo Payload Option [RFC2675]. While the HBH Control 201 Options contain information that is useful to a router's control 202 plane, e.g. the Router Alert Option [RFC2711]. Currently, both HBH 203 forwarding and control options are carried in the same HBH Options 204 header. There is no specification defining rules for differentiating 205 the process of the two kinds of options. 207 According to the common configuration in the current networks, i.e. 208 to assign packets containing a Hop-by-Hop Options header (indicated 209 by the Next Header = 0) to a slow processing path, all the HBH 210 Options will be sent to the control plane of the nodes. It impacts 211 the normal IP forwarding procedure of the packets containing the HBH 212 forwarding options which should be processed in the forwarding plane. 213 As stated above, it also introduces a severe risk of DoS attacks 214 using HBH headers. 216 If all the HBH Options are forced to be processed first in the 217 forwarding plane and then classified according to the HBH Option 218 Type, it requires the consumption of the forwarding plane resources 219 to make such processing selection, which will impact the forwarding 220 efficiency. Moreover, there are some existing nodes that are 221 configured to assign the packets containing a Hop-by-Hop Options 222 header to the control plane of the nodes cannot be reconfigured. 224 Appendix of this document provides the classification of the 225 currently defined HBH options into HBH forwarding options and HBH 226 control options, and the HBH forwarding options are in the majority. 228 2.3. Service Requirements 230 As listed in the Appendix, there have been over ten HBH options 231 already specified in RFCs and the specified forwarding options are in 232 the majority. As IPv6 is being rapidly and widely deployed 233 worldwide, more and more applications and network services are 234 migrating to or adopting IPv6. More and more new services that 235 requires hop-by-hop forwarding process behavior are emerging and the 236 HBH Options header is going to be utilized by new services in various 237 use scenarios. 239 As more services start utilizing the HBH Options header, more packets 240 containing HBH Options are going to be injected into the networks. 242 According to the current common configuration in most network 243 deployments, all the packets of the new services are going to be sent 244 to the control plane of the nodes, with the possible consequence of 245 causing a DoS effect on the control plane. The packets will be 246 dropped and the normal IP forwarding may be severely impacted. The 247 deployment of new network services involving multi-vendor 248 interoperability will become impossible. 250 In-situ OAM with IPv6 encapsulation [draft-ietf-ippm-ioam- 251 ipv6-options] is one of the examples. IOAM in IPv6 is used to 252 enhance diagnostics of IPv6 networks and complements other 253 mechanisms, such as the IPv6 Performance and Diagnostic Metrics 254 Destination Option described in [RFC8250]. The IOAM data fields are 255 encapsulated in "option data" fields of the Hop-by-Hop Options header 256 if Pre-allocated Tracing Option, Incremental Tracing Option, or Proof 257 of Transit Option are carried [I-D.ietf-ippm-ioam-data], that is, the 258 IOAM performs per hop. 260 As above mentioned, according to the current common configuration, 261 all the packets employing IOAM are going to be sent to the control 262 plane of every node along the path, it will cause a severe effect DoS 263 on the control plane. The packets will be inconsistently dropped and 264 the normal IP forwarding will be severely impacted. The end-to-end 265 deployment of IOAM in a network involving nodes from multiple vendors 266 is impossible. 268 3. Proposal 270 3.1. Hop-by-Hop Forwarding Options Header 272 We propose to define a new HBH Forwarding Options header dedicated to 273 carry the HBH Forwarding Options. The IPv6 packets containing this 274 Hop-by-Hop Forwarding Options header will be only processed in the 275 forwarding plane and MUST NOT be sent to the control plane of the 276 network nodes. 278 The Hop-by-Hop Forwarding Options header is identified by a Next 279 Header value of TBD in the IPv6 header and has the following format: 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Next Header | Hdr Ext Len | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 284 | | 285 . . 286 . HBH Forwarding Options . 287 . . 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Next Header 8-bit selector. Identifies the type of header 292 immediately following the Hop-by-Hop 293 Forwarding Options header. 295 Hdr Ext Len 8-bit unsigned integer. Length of the 296 Hop-by-Hop Forwarding Options header in 8-octet 297 units, not including the first 8 octets. 299 Options Variable-length field, of length such that the 300 complete Hop-by-Hop Options header is an 301 integer multiple of 8 octets long. Contains 302 one or more TLV-encoded HBH forwarding options. 304 The Hop-by-Hop Forwarding Options header is recommended to be placed 305 immediately after the IPv6 header. 307 The Hop-by-Hop Forwarding Options follows the formatting guidelines 308 specified in the Appendix A. of [RFC8200]. 310 3.2. The usage of the existing Hop-by-Hop Options Header 312 The existing Hop-by-Hop Options Header, identified by a Next Header 313 value of zero in the IPv6 header, can still be used for carrying the 314 HBH control options. The IPv6 packets carrying such HBH control 315 options will be sent to the control plane anyway, so it follows the 316 exact current processing procedures. 318 4. Security Considerations 320 It is the same as the Security Considerations in [RFC8200] for the 321 part related with the HBH Options header. 323 5. IANA Considerations 325 TBD: Next Header for Hop-by-Hop Forwarding Options Header 327 6. Appendix. Existing HBH Options 329 We further classify the HBH Options into HBH Forwarding and HBH 330 Control Options. We can see that among all the defined HBH Options 331 the HBH Forwarding Options are in the majority. 333 HBH Forwarding Options: 335 o PAD Options: PAD1 and PADn [RFC8200] 337 o Jumbo Payload [RFC2675] 339 o RPL Option [RFC6553] 341 o Common Architecture Label 1Pv6 Security Option [RFC5570] 343 o SMF Option [RFC6621] 345 o MPL Option [RFC7731] 347 o DFF Option [RFC6971] 349 o MTU Option [I-D.ietf-6man-mtu-option] 351 o AltMark Option [I-D.ietf-6man-ipv6-alt-mark] 353 HBH Control Options: 355 o Router Alert Option [RFC2711] 357 o Quickstart Option [RFC4782] 359 7. References 361 7.1. Normative References 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 369 of IPv6 Extension Headers", RFC 7045, 370 DOI 10.17487/RFC7045, December 2013, 371 . 373 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 374 "Observations on the Dropping of Packets with IPv6 375 Extension Headers in the Real World", RFC 7872, 376 DOI 10.17487/RFC7872, June 2016, 377 . 379 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 380 (IPv6) Specification", STD 86, RFC 8200, 381 DOI 10.17487/RFC8200, July 2017, 382 . 384 7.2. Informative References 386 [I-D.ietf-6man-ipv6-alt-mark] 387 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 388 Pang, "IPv6 Application of the Alternate Marking Method", 389 draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 390 2020. 392 [I-D.ietf-6man-mtu-option] 393 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 394 by-Hop Option", draft-ietf-6man-mtu-option-02 (work in 395 progress), March 2020. 397 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 398 RFC 2675, DOI 10.17487/RFC2675, August 1999, 399 . 401 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 402 RFC 2711, DOI 10.17487/RFC2711, October 1999, 403 . 405 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 406 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 407 January 2007, . 409 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 410 Architecture Label IPv6 Security Option (CALIPSO)", 411 RFC 5570, DOI 10.17487/RFC5570, July 2009, 412 . 414 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 415 Power and Lossy Networks (RPL) Option for Carrying RPL 416 Information in Data-Plane Datagrams", RFC 6553, 417 DOI 10.17487/RFC6553, March 2012, 418 . 420 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 421 RFC 6621, DOI 10.17487/RFC6621, May 2012, 422 . 424 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 425 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 426 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 427 . 429 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 430 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 431 February 2016, . 433 Authors' Addresses 435 Zhenbin Li 436 Huawei 437 Beijing 100095 438 China 440 Email: lizhenbin@huawei.com 442 Shuping Peng 443 Huawei 444 Beijing 100095 445 China 447 Email: pengshuping@huawei.com