idnits 2.17.1 draft-hinden-6man-hbh-processing-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 : ---------------------------------------------------------------------------- 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 (3 December 2020) is 1233 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: 'RFC2460' is mentioned on line 274, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) == Missing Reference: 'CHARLES LYNN' is mentioned on line 350, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-HBH' == Outdated reference: A later version (-15) exists of draft-ietf-6man-mtu-option-04 == Outdated reference: A later version (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-42 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Hinden 3 Internet-Draft Check Point Software 4 Updates: 8200 (if approved) G. Fairhurst 5 Intended status: Standards Track University of Aberdeen 6 Expires: 6 June 2021 3 December 2020 8 IPv6 Hop-by-Hop Options Processing Procedures 9 draft-hinden-6man-hbh-processing-00 11 Abstract 13 This document specifies procedures for how IPv6 Hop-by-Hop options 14 are processed. It modifies the procedures specified in the IPv6 15 Protocol Specification (RFC8200) to make processing in routers more 16 practical with the goal of making IPv6 Hop-by-Hop options useful to 17 deploy in the Internet. When published, this document updates 18 RFC8200. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 6 June 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 5. Hop-by-Hop Header Processing Procedures . . . . . . . . . . . 5 58 5.1. Hop-by-Hop Options Per Packet . . . . . . . . . . . . . . 5 59 5.2. Hop-by-Hop Headers Processing . . . . . . . . . . . . . . 6 60 5.3. Configuration . . . . . . . . . . . . . . . . . . . . . . 6 61 6. Hop-by-Hop Option Header Alignment . . . . . . . . . . . . . 7 62 6.1. Hop-by-Hop Options that Meet Alignment Requirement . . . 7 63 6.2. Hop-by-Hop Options that Must be Deprecated or Modified . 8 64 6.3. Destination Options and Deprecated Hop-by-Hop Options . . 8 65 7. New Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 70 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 71 13. Informative References . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This document specifies procedures for how IPv6 Hop-by-Hop options 77 are processed. It modifies the procedures specified in the IPv6 78 Protocol Specification (RFC8200) to make processing in routers more 79 practical with the goal of making IPv6 Hop-by-Hop options useful to 80 deploy in the Internet. 82 When published this document updates [RFC8200]. 84 The current list of defined Hop-by-Hop options can be found at 85 [IANA-HBH]. 87 2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 3. Terminology 97 This document uses the following loosely defined terms: 99 * Fast path: Hardware or Application-Specific Integrated Circuit 100 (ASIC) processing path for packets. This is the usual processing 101 path within a router for IP datagrams. It is sometimes also 102 described as the forwarding plane. 104 * Slow path: Software processing path for packets. This is a 105 special processing path for packets that require special 106 processing or differ from assumptions made in fast-path 107 heuristics, or for router control protocols. It is sometimes also 108 described as the control plane. 110 4. Background 112 In the first version of the IPv6 specification, Hop-by-Hop options 113 were required to be processed by all nodes, routers and hosts. This 114 proved to not be practical in high speed routers due to several 115 factors, including: 117 * Inability to process the hop-by-hop options at wire speed in 118 hardware. 120 * Hop-by-Hop options would be sent to the "slow path". This could 121 could degrade the routers performance and it's ability to process 122 important control traffic. 124 * A mechanism that forces external packets to the routers "slow 125 path" could be exploited as a Denial of Service attack on the 126 router. 128 * Packets could contain multiple Hop-by-Hop options making the 129 previous issues worse by increasing the complexity required to 130 process them. 132 When the IPv6 Specification was updated and published in July 2017 as 133 [RFC8200], the procedures relating to hop-by-hop options are as 134 follows: 136 Extension headers (except for the Hop-by-Hop Options header) are 137 not processed, inserted, or deleted by any node along a packet's 138 delivery path, until the packet reaches the node (or each of the 139 set of nodes, in the case of multicast) identified in the 140 Destination Address field of the IPv6 header. 142 The Hop-by-Hop Options header is not inserted or deleted, but may 143 be examined or processed by any node along a packet's delivery 144 path, until the packet reaches the node (or each of the set of 145 nodes, in the case of multicast) identified in the Destination 146 Address field of the IPv6 header. The Hop-by-Hop Options header, 147 when present, must immediately follow the IPv6 header. Its 148 presence is indicated by the value zero in the Next Header field 149 of the IPv6 header. 151 NOTE: While [RFC2460] required that all nodes must examine and 152 process the Hop-by-Hop Options header, it is now expected that 153 nodes along a packet's delivery path only examine and process the 154 Hop-by-Hop Options header if explicitly configured to do so. 156 The changes meant that an implementation complied with the IPv6 157 specification even if it did not process hop-by-hop options, and that 158 it was expected that routers would add configuration information to 159 control which hop-by-hop options they would process. 161 Unfortunately, this did not improve the processing of Hop-by-Hop 162 options and they are often not possible to be deployed and used in 163 the Internet. It merely documented how they were being used in the 164 Internet. 166 In hindsight, hop-by-hop options were still not practical to be used 167 widely in the Internet. Many operational routers are configured to 168 drop all packets containing a hop-by-hop option header. The main 169 issues remain: 171 * Routers have been configured to drop transit data packets that 172 would be processed in the fast path, this includes dropping hop- 173 by-hop packets that would need to be processed in the fast path. 175 * Allowing multiple hop-by-hop options in a single packet makes it 176 even more expensive in router resources to process these packets 177 in the fast path. It adds complexity to the number of 178 permutations that might need to be processed. 180 * Any mechanism that can be used externally to force packets into 181 the router's slow path can be exploited as a denial of service 182 attack on a transit router by saturating the resources need for 183 router management protocols (e.g., routing protocols, network 184 management protocols, etc.) that may cause the router to fail. 185 This issue for the Router Alert option, which intentionally places 186 packets on the slow path, is discussed in [RFC6398]. Section 3 of 187 this RFC includes a good summary: 189 "In a nutshell, the IP Router Alert Option does not provide a 190 convenient universal mechanism to accurately and reliably 191 distinguish between IP Router Alert packets of interest and 192 unwanted IP Router Alert packets. This, in turn, creates a 193 security concern when the IP Router Alert Option is used, because, 194 short of appropriate router-implementation-specific mechanisms, 195 the router slow path is at risk of being flooded by unwanted 196 traffic." 198 There has been some academic research that discussed the general 199 problem with dropping packets containing IPv6 extension headers, 200 including the Hop-by-Hop Options header. For example [Hendriks] 201 states that "dropping all packets with Extension Headers, is a bad 202 practice", and that "The share of traffic containing more than one EH 203 however, is very small. For the design of hardware able to handle 204 the dynamic nature of EHs, we therefore recommend to support at least 205 one EH" 207 This document defines a set of procedures for the hop-by-hop option 208 header that make the processing of hop-by-hop options practical in 209 modern transit routers. 211 5. Hop-by-Hop Header Processing Procedures 213 This section describes three sets of changes to [RFC8200]. 215 5.1. Hop-by-Hop Options Per Packet 217 The Hop-by-Hop Option Header as defined in Section 4.3 of [RFC8200] 218 is identified by a Next Header value of 0 in the IPv6 header. 219 Section 4.1 requires a Hop-by-Hop Options header to appear 220 immediately after the IPv6 header. [RFC8200] also requires that a 221 Hop-by-Hop Options header can only appear once in a packet. 223 The Hop-by-Hop Options Header as defined in [RFC8200] can contain one 224 or more Hop-by-Hop options. This document updates [RFC8200] such 225 that there MUST only be one option contained in an Hop-by-Hop Options 226 header in a single packet. The motivation for this change is to 227 simplify the processing of Hop-by-Hop options in the fast path. 229 Nodes creating packets with a Hop-by-Hop option headers MUST only 230 include a single option in the packet. This also requires that all 231 Hop-by-Hop Options MUST be 8-octet aligned. See Section 6 for more 232 detail. 234 Nodes processing a packet with a Hop-by-Hop options header MUST 235 discard the packet if there is more than one Hop-by-Hop option in 236 that header. 238 5.2. Hop-by-Hop Headers Processing 240 Section 4.2 of [RFC8200] defines an Option Type field in options that 241 controls how the option is processed if the IPv6 node processing the 242 option header does not recognize the Option Type. This document 243 modifies that behavior for options carried in an Hop-by-Hop Option 244 header in two ways. 246 IPv6 nodes MUST only process an Hop-by-Hop Options header if it can 247 be done in the fast path of the router. If the IPv6 node can not 248 process the Hop-by-Hop Option header in the fast path is MUST skip 249 over this option and continue processing the header normally. 251 Section 4.2 of [RFC8200] defines the Option Type identifiers as 252 internally encoded such that their highest-order 2 bits specify the 253 action that must be taken if the processing IPv6 node does not 254 recognize the Option Type. This document modifies this behaviour for 255 Hop-by-Hop options as follows: 257 00 - skip over this option and continue processing the header. 259 01 - discard the packet. 261 10 - discard the packet. 263 11 - discard the packet. 265 The motivation for this change is to simplify what the router needs 266 to do in the fast path when it can not recognize the Option Type. It 267 is no longer required to send ICMP Parameter Problem messages. 269 5.3. Configuration 271 Section 4 of [RFC8200] allows for a router to control it's processing 272 of IPv6 Hop-by-Hop options by local configuration. The text is: 274 NOTE: While [RFC2460] required that all nodes must examine and 275 process the Hop-by-Hop Options header, it is now expected that 276 nodes along a packet's delivery path only examine and process the 277 Hop-by-Hop Options header if explicitly configured to do so. 279 A possible approach to implementing this is to maintain a lookup 280 table based on Option Type of the IPv6 options that are supported in 281 the fast path. This would allow for a node to quickly determine if 282 an option is supported and can be processed. If the option is not 283 supported, then the node processes it as described in Section 5.2 of 284 this document. 286 The actions of the lookup table SHOULD be configurable by the 287 operator of the router. 289 6. Hop-by-Hop Option Header Alignment 291 [RFC8200] requires all extension headers to be 8-octet aligned. The 292 text from Section 4 is: 294 Each extension header is an integer multiple of 8 octets long, in 295 order to retain 8-octet alignment for subsequent headers. 297 Two types of Pad options are defined to keep this alignment, that is 298 Pad1 and PadN, if the options in an Destination Option Header or Hop- 299 by-Hop Option Header do not result in 8-octet alignment. 301 This document requires all Hop-by-Hop Options to be 8-octet aligned 302 (see Section 5.1). This eliminates the need for Pad options to be 303 used in the Hop-by-Hop Option header to make them 8-octet aligned. 305 The current list of defined Destination and Hop-by-Hop options can be 306 found at [IANA-HBH]. 308 The following sections list current Hop-by-Hop Options that meet the 309 alignment requirement defined here (Section 6.1) or if they need to 310 be be deprecated or modified (Section 6.2). Hop-by-Hop Options that 311 have been deprecated, and Destination Options are listed separately 312 in Section 6.3. Pad Options (Pad1 and PadN), and RFC3692-style 313 Experiment options are not listed. 315 6.1. Hop-by-Hop Options that Meet Alignment Requirement 317 The following Hop-by-Hop Options meet the alignment requirements 318 defined in this section: 320 * Jumbo Payload [RFC2675] 321 * Path MTU Record Option [I-D.ietf-6man-mtu-option] 322 * RPL Option [I-D.ietf-roll-useofrplinfo] *** 323 * Quick-Start [RFC4782] 324 * CALIPSO [RFC5570] *** 325 * SMF_DPD [RFC6621] *** 326 * ILNP Nonce [RFC6744] *** 327 * MPL Option [RFC7731] 329 *** Note: Need to verify that these options are 8-octet aligned. 331 6.2. Hop-by-Hop Options that Must be Deprecated or Modified 333 The Hop-by-Hop Options listed in this section do not meet the 334 alignment requirements defined in this section. They either need to 335 be deprecated or modified to support 8-octet alignment without the 336 use of Pad options. If there is interest in modifying them, it 337 should be straightforward to make them have 8-octet alignment. 339 * Router Alert [RFC2711] 340 * IP_DFF [RFC6971] 341 * IOAM [I-D.ietf-ippm-ioam-ipv6-options] 343 6.3. Destination Options and Deprecated Hop-by-Hop Options 345 The options listed in this section are either Destination Options or 346 Deprecated Hop-by-Hop Options. 8-octet alignment is not an issue. 348 * Tunnel Encapsulation Limit [RFC2473] 349 * RPL Option (DEPRECATED) [RFC6553] 350 * Endpoint Identification (DEPRECATED) [CHARLES LYNN] 351 * MPL Option (DEPRECATED) [RFC7731] 352 * Home Address [RFC6275] 353 * Line-Identification Option [RFC6788] 354 * Performance and Diagnostic Metrics (PDM) [RFC8250] 356 7. New Hop-by-Hop Options 358 Any new IPv6 Hop-by-Hop option defined in the future should have 359 8-octet alignment without the use of any Pad options. This 360 requirement modifies Section 4.8 of [RFC8200]. 362 8. IANA Considerations 364 This draft has no actions for the IANA. 366 9. Security Considerations 368 TBD 370 10. Acknowledgments 372 Helpful comments were received from Brian Carpenter, Ron Bonica, Ole 373 Troan, [your name here], and other members of the 6MAN working group. 375 11. Change log [RFC Editor: Please remove] 377 draft-hinden-6man-hbh-processing-00, 2020-Nov-29: Initial draft. 379 12. Normative References 381 [IANA-HBH] "Destination Options and Hop-by-Hop Options", 382 . 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 391 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 392 May 2017, . 394 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 395 (IPv6) Specification", STD 86, RFC 8200, 396 DOI 10.17487/RFC8200, July 2017, 397 . 399 13. Informative References 401 [Hendriks] Hendriks, L., Velan, P., Schmidt, RO., Boer, P., and A. 402 Aiko, "Threats and Surprises behind IPv6 Extension 403 Headers", August 2017, 404 . 407 [I-D.ietf-6man-mtu-option] 408 Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- 409 by-Hop Option", Work in Progress, Internet-Draft, draft- 410 ietf-6man-mtu-option-04, 23 October 2020, 411 . 414 [I-D.ietf-ippm-ioam-ipv6-options] 415 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 416 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 417 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 418 Smith, "In-situ OAM IPv6 Options", Work in Progress, 419 Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-04, 1 420 November 2020, . 423 [I-D.ietf-roll-useofrplinfo] 424 Robles, I., Richardson, M., and P. Thubert, "Using RPI 425 Option Type, Routing Header for Source Routes and IPv6-in- 426 IPv6 encapsulation in the RPL Data Plane", Work in 427 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-42, 428 12 November 2020, . 431 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 432 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 433 December 1998, . 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 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 453 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 454 2011, . 456 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 457 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 458 2011, . 460 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 461 Power and Lossy Networks (RPL) Option for Carrying RPL 462 Information in Data-Plane Datagrams", RFC 6553, 463 DOI 10.17487/RFC6553, March 2012, 464 . 466 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 467 RFC 6621, DOI 10.17487/RFC6621, May 2012, 468 . 470 [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination 471 Option for the Identifier-Locator Network Protocol for 472 IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November 473 2012, . 475 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 476 Nordmark, "The Line-Identification Option", RFC 6788, 477 DOI 10.17487/RFC6788, November 2012, 478 . 480 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 481 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 482 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 483 . 485 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 486 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 487 February 2016, . 489 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 490 Performance and Diagnostic Metrics (PDM) Destination 491 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 492 . 494 Authors' Addresses 496 Robert M. Hinden 497 Check Point Software 498 959 Skyway Road 499 San Carlos, CA 94070 500 United States of America 502 Email: bob.hinden@gmail.com 504 Godred Fairhurst 505 University of Aberdeen 506 School of Engineering, Fraser Noble Building 507 Aberdeen 508 AB24 3UE 509 United Kingdom 511 Email: gorry@erg.abdn.ac.uk