idnits 2.17.1 draft-ietf-6man-hbh-header-handling-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 (Using the creation date from RFC2460, updated by this document, for RFC5378 checks: 1997-07-30) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2016) is 2969 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) == Unused Reference: 'RFC4302' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-gont-v6ops-ipv6-ehs-packet-drops-02 == Outdated reference: A later version (-13) exists of draft-ietf-6man-rfc2460bis-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance F. Baker 3 Internet-Draft Cisco Systems 4 Updates: 2460,7045 (if approved) R. Bonica 5 Intended status: Standards Track Juniper Networks 6 Expires: September 9, 2016 March 8, 2016 8 IPv6 Hop-by-Hop Options Extension Header 9 draft-ietf-6man-hbh-header-handling-02 11 Abstract 13 This document clarifies requirements for IPv6 routers with respect to 14 the Hop-by-Hop (HBH) Options Extension Header. These requirements 15 are applicable to all IPv6 routers, regardless of whether they 16 maintain a strict separation between forwarding and control plane 17 hardware. In this respect, this document updates RFC 2460 and RFC 18 7045. 20 This document also describes forwarding plane procedures for 21 processing the HBH Options Extension Header. These procedures are 22 applicable to implementations that maintain a strict separation 23 between forwarding and control plane implementations. 25 The procedures described herein satisfy the above mentioned 26 requirements by processing HBH Options on the forwarding plane to the 27 greatest degree possible. If a packet containing HBH Options must be 28 dispatched to the control plane, it is rate limited before 29 dispatching. In order to comply with the requirements of this 30 specification, implementations may execute the procedures described 31 herein or any other procedures that result in compliant behavior. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 9, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Proposed Procedures . . . . . . . . . . . . . . . . . . . . . 6 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 7.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 78 Appendix B. HBH Options . . . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 In IPv6 [RFC2460], optional Internet-layer information is encoded in 84 extension headers that may be placed between the IPv6 header and the 85 upper-layer header. Currently, eleven extension headers are defined. 86 Among them is the Hop-by-Hop (HBH) Options Extension header. Unlike 87 any other extension header, the HBH Options Extension header is 88 examined by every node that a packet visits en route to its 89 destination. 91 The HBH Extension Header contains one or more HBH Options. Each HBH 92 Option contains a type identifier. Appendix B of this document 93 provides a list of currently defined HBH options. 95 Some HBH Options contain information that is useful to a router's 96 forwarding plane. In this document, we call these options "HBH 97 forwarding options". Among these is the Jumbo Payload Option 99 [RFC2675]. The Jumbo Payload Option indicates the payload length of 100 the packet that carries it. While this information is required to 101 forward the packet, it can be discarded as soon as the packet has 102 been forwarded. 104 By contrast, other HBH Options contain information that is useful to 105 a router's control plane. In this document, we call these options 106 "HBH control options". Among these is the Router Alert Option 107 [RFC2711]. The Router Alert Option informs transit routers that the 108 packet carrying it contains information to be consumed by the 109 router's control plane. In many cases, this information is used to 110 forward subsequent packets. 112 Finally, the Pad and Pad1 options contain no information at all. 113 These are included to ensure word-alignment of subsequent options and 114 headers. 116 Many modern routers maintain a strict separation between forwarding 117 plane hardware and control plane hardware. In these routers, 118 forwarding plane bandwidth is plentiful, while control plane 119 bandwidth is constrained. In order to protect scarce control plane 120 resources, these routers enforce policies the restrict access from 121 the from the forwarding plane to the control plane. Effective 122 policies address packets containing the HBH Options Extension header, 123 because HBH control options require access from the forwarding plane 124 to the control plane. 126 Many network operators perceive HBH Options to be a breach of the 127 separation between the forwarding and control planes 128 [I-D.ietf-v6ops-ipv6-ehs-in-real-world]. Therefore, some network 129 operators discard all packets containing the HBH Options Extension 130 Header, while others forward the packets but ignore the HBH Options. 131 Still other operators severely rate-limit packets containing the HBH 132 Options Extension Header. In addition, some (notably older) 133 implementations send all packets containing a HBH header to the 134 control plane even if they contain only pad options, resulting in an 135 effect DoS on the router and inconsistent drops among those packets 136 due to rate limiting or other factors. 138 [RFC7045] legitimizes the current state of affairs, severely limiting 139 the utility of HBH options. In the words of RFC 7045: 141 "The IPv6 Hop-by-Hop Options header SHOULD be processed by 142 intermediate forwarding nodes as described in RFC2460. However, 143 it is to be expected that high-performance routers will either 144 ignore it or assign packets containing it to a slow processing 145 path. Designers planning to use a Hop-by-Hop option need to be 146 aware of this likely behaviour." 148 This document clarifies requirements for IPv6 routers with respect to 149 the HBH Options Extension Header. These requirements are applicable 150 to all IPv6 routers, regardless of whether they maintain a strict 151 separation between forwarding and control plane hardware. In this 152 respect, this document updates RFC 2460 and RFC 7045. 154 This document also describes forwarding plane procedures for 155 processing the HBH Options Extension Header. These procedures are 156 applicable to implementations that maintain a strict separation 157 between forwarding and control plane hardware. 159 The procedures described herein satisfy the above mentioned 160 requirements by processing HBH Options on the forwarding plane to the 161 greatest degree possible. If a packet containing HBH Options must be 162 dispatched to the control plane, it is rate limited before 163 dispatching. In order to comply with the requirements of this 164 specification, implementations can execute the procedures described 165 herein or any other procedures that result in compliant behavior. 167 1.1. Requirements Language 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 2. Requirements 175 This section clarifies requirements for IPv6 routers with respect to 176 the HBH Options Extension Header. These requirements are applicable 177 to all IPv6 routers, regardless of whether they maintain a strict 178 separation between forwarding and control plane hardware. 180 o REQ1: Implementations MUST NOT discard otherwise forwardable 181 packets because they contain the HBH Options Extension header. 182 However, an implementation MAY be configured to discard packets 183 containing the HBH Options Extension Header, so long as this is 184 not the default behavior. 186 o REQ 2: Implementations MUST scan the entire HBH Options Extension 187 header, processing unrecognized options as described in 188 Section 4.2 of RFC 2460. Specifically, if an implementation 189 receives a packet that contains an unrecognized HBH Option, the 190 implementation MUST examine the first two bits of the Type 191 indicator contained by the unrecognized option. Those bits 192 determine whether the implementation will a) continue to process 193 the packet, b) discard the packet without sending an ICMP message 194 or c) discard the packet and send an ICMP message. 196 o REQ 3: If an implementation receives a packet that contains 197 multiple unrecognized HBH Options, and at least one of those 198 unrecognized options contains a Type indicator whose first two bit 199 are 01, the implementation MUST discard the packet, without 200 sending an ICMP message. The implementation MUST NOT send an ICMP 201 message, even if one of the other unrecognized options contains a 202 Type indicator that begins with 10 or 11. This rule applies 203 regardless of the ordering of options within the extension header. 205 o REQ 4: Implementations MUST protect themselves against denial of 206 service attack against the forwarding plane that are propagated 207 through HBH Options. These protections MUST be enabled by 208 default, without special configuration. 210 o REQ 5: Implementations MUST protect themselves against denial of 211 service attack against the control plane that are propagated 212 through HBH Options. These protections MAY require special 213 configuration. 215 o REQ 6: The originator of a packet MAY insert the HBH Options 216 Extension header between the IPv6 header and the upper-layer 217 header. It MAY also insert HBH Options inside of the HBH Options 218 header. Transit routers MUST NOT insert the HBH Options Extension 219 header between the IPv6 header and the upper-layer header. 220 Furthermore, they MUST NOT add or delete HBH Options inside of the 221 HBH Options Extension header. 223 o REQ 7: Implementations SHOULD support a configuration option that 224 limits the set of HBH Options that they recognize. For example, 225 assume that an implementation recognizes a particular HBH Option. 226 Using this configuration option, an operator can cause the 227 implementation to behave as if it does not recognize that option. 228 This MAY be configured a side effect of other functionality. For 229 example, an implementation might not recognize the Router Alert 230 Option unless a protocol that relies on the Router Alert Option 231 (e.g., RSVP) is configured. 233 o REQ 8: The HBH Options Extension Header can contain as many as 234 2056 bytes. Some implementation are not capable of processing 235 extension headers of that length 236 [I-D.gont-v6ops-ipv6-ehs-packet-drops]. When an implementation 237 receives a packet that it cannot process due to its HBH Options 238 Extension Header length, the implementation MUST discard the 239 packet and send an ICMP Parameter Problem message the packet 240 source. ICMP Parameter Problem Code MUST be "Long Extension 241 Header" (value TBD) and the ICMP Parameter Problem Pointer MUST 242 contain the offset of HBH Options Extension Header. 244 3. Proposed Procedures 246 This section describes forwarding plane procedures for processing the 247 HBH Options Extension Header. These procedures are applicable to 248 implementations that maintain a strict separation between forwarding 249 and control plane hardware. 251 The procedures described below process HBH Options on the forwarding 252 plane to the greatest degree possible. If a packet containing HBH 253 Options must be dispatched to the control plane, it is rate limited 254 before dispatching. In order to comply with the requirements of 255 Section 2, implementations can execute the procedures described 256 herein or any other procedures that result in compliant behavior. 258 Having received a packet containing the HBH Options Extension header, 259 the forwarding plane determines whether the HBH Options Extension 260 Header is too long for it to process. If so, the forwarding plane 261 discards the packet and sends an ICMP Parameter Problem message to 262 the packet source. ICMP Parameter Problem Code is set to "Long 263 Extension Header" and the ICMP Parameter Problem Pointer is set to 264 the offset of HBH Options Extension Header. 266 If the HBH Options Extension Header is not too long to process, the 267 forwarding plane hardware scans the header, assigning it to one of 268 the following classes: 270 o Discard 272 o Dispatch to control plane 274 o Forward, ignoring all HBH Option 276 o Forward, processing selected HBH Options 278 Forwarding plane hardware discards the packet if the HBH Options 279 Extension Header contains an unrecognized option whose Type indicator 280 begins with 01, 10 or 11. Forwarding plane hardware sends an ICMP 281 message if required. See Section 2 REQ 2 and REQ 3 for details. 283 If the packet is not discarded, and the HBH Options Extension header 284 contains at least one recognized control option, the forwarding plane 285 subjects the packet to a rate-limit and dispatches it to the control 286 plane 288 Otherwise, if the HBH Options Extension header contains only the 289 following option types, the packet is forwarded without further HBH 290 Option processing: 292 o Pad or Pad1 294 o Unrecognized options whose Type indicator begins with 00 296 Otherwise, the forwarding plane process forwarding options and 297 forwards the packet 299 4. IANA Considerations 301 IANA is requested to assign a new entry to the ICMP Parameter Problem 302 Code registry. The name of this code is "Long Extension Header". 304 5. Security Considerations 306 This document contributes to the security of IPv6 routers, by 307 defining forwarding plane procedures for the processing of HBH 308 Options. These procedures are applicable to implementations that 309 maintain a strict separation between forwarding and control plane 310 hardware. 312 The procedures described below process HBH Options on the forwarding 313 plane to the greatest degree possible. If a packet containing HBH 314 Options must be dispatched to the control plane, it is rate limited 315 before dispatching. 317 6. Acknowledgements 319 This note grew out of a discussion among the author, Ole Troan, Mark 320 Townsley, Frank Brockners, and Shwetha Bhandari, and benefited from 321 comments by Dennis Ferguson, Brian Carpenter, Panos Kampanakis, 322 Jinmei Tatuya, and Joe Touch. Thanks to Fernando Gont for his 323 thoughtful review. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 335 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 336 December 1998, . 338 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 339 of IPv6 Extension Headers", RFC 7045, 340 DOI 10.17487/RFC7045, December 2013, 341 . 343 7.2. Informative References 345 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 346 Gont, F., Hilliard, N., Doering, G., LIU, S., and W. 347 Kumari, "Operational Implications of IPv6 Packets with 348 Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- 349 drops-02 (work in progress), February 2016. 351 [I-D.ietf-6man-rfc2460bis] 352 Deering, S. and B. Hinden, "Internet Protocol, Version 6 353 (IPv6) Specification", draft-ietf-6man-rfc2460bis-03 (work 354 in progress), January 2016. 356 [I-D.ietf-roll-trickle-mcast] 357 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 358 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 359 mcast-12 (work in progress), June 2015. 361 [I-D.ietf-v6ops-ipv6-ehs-in-real-world] 362 Gont, F., Linkova, J., Chown, T., and S. LIU, 363 "Observations on the Dropping of Packets with IPv6 364 Extension Headers in the Real World", draft-ietf-v6ops- 365 ipv6-ehs-in-real-world-02 (work in progress), December 366 2015. 368 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 369 RFC 2675, DOI 10.17487/RFC2675, August 1999, 370 . 372 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 373 RFC 2711, DOI 10.17487/RFC2711, October 1999, 374 . 376 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 377 DOI 10.17487/RFC4302, December 2005, 378 . 380 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 381 RFC 4303, DOI 10.17487/RFC4303, December 2005, 382 . 384 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 385 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 386 January 2007, . 388 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 389 Architecture Label IPv6 Security Option (CALIPSO)", 390 RFC 5570, DOI 10.17487/RFC5570, July 2009, 391 . 393 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 394 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 395 2011, . 397 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 398 Power and Lossy Networks (RPL) Option for Carrying RPL 399 Information in Data-Plane Datagrams", RFC 6553, 400 DOI 10.17487/RFC6553, March 2012, 401 . 403 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 404 RFC 6621, DOI 10.17487/RFC6621, May 2012, 405 . 407 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 408 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 409 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 410 . 412 Appendix A. Change Log 414 RFC Editor: this section need not be published in any RFC. 416 Initial Version: October 2015: text copied from draft-baker-6man- 417 hbh-header-handling-03.txt and discussed in IETF 94 419 IETF 94 Update: Sections 2.2, 2..3, and 2.4 moved to an appendix 420 reflecting (negative) working group viewpoint on the modification 421 of packet length in flight. 423 The content of this document is likely to be subsumed into 2460bis 424 [I-D.ietf-6man-rfc2460bis], but is held separate for the present 425 discussion. 427 A new section 2.2 added detailing conceptual processing model for 428 HBH options. 430 version 2 Addressed editorial comments 432 Appendix B. HBH Options 434 At this writing, there are several defined Hop-by-Hop options: 436 PAD Options: The PAD1 and PADn [RFC2460] 438 Router Alert Option: The IPv6 Router Alert Option [RFC2711] 439 [RFC6398] 441 Jumbo Payload: [RFC2675] 443 RPL Option: [RFC6553] 445 Quickstart Option [RFC4782] 447 Common Architecture Label IPv6 Security Option: [RFC5570] 449 SMF Option: [RFC6621] 451 MPL Option: [I-D.ietf-roll-trickle-mcast] 453 DFF Option: [RFC6971] 455 Authors' Addresses 457 Fred Baker 458 Cisco Systems 459 Santa Barbara, California 93117 460 USA 462 Email: fred@cisco.com 464 Ron Bonica 465 Juniper Networks 466 Herndon, Virginia 20171 467 USA 469 Email: rbonica@juniper.net