idnits 2.17.1 draft-ietf-6man-hbh-header-handling-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2460, but the abstract doesn't seem to directly say this. It does mention RFC2460 though, so this could be OK. 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 (November 3, 2015) is 3090 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-ietf-v6ops-ipv6-ehs-in-real-world-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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) November 3, 2015 5 Intended status: Standards Track 6 Expires: May 6, 2016 8 IPv6 Hop-by-Hop Header Handling 9 draft-ietf-6man-hbh-header-handling-00 11 Abstract 13 This note updates the IPv6 Specification (RFC 2460), specifically 14 commenting on the Hop-by-Hop Options Header (section 4.3) and option 15 format and handling (section 4.2). 17 It also updates RFC 7045, which noted that RFC 2460 is widely 18 violated in this respect, but merely legitimized this situation with 19 a SHOULD. The present document tries to address the issue more 20 fundamentally. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 6, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Handling of options in extension headers . . . . . . . . . . 3 59 2.1. Hop-by_hop Options . . . . . . . . . . . . . . . . . . . 3 60 2.2. Changing options in transit . . . . . . . . . . . . . . . 4 61 2.3. Adding headers or options in transit . . . . . . . . . . 5 62 2.4. Interactions with the Security Extension Header . . . . . 5 63 3. Interoperation with RFC 2460 . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The IPv6 Specification [RFC2460] specifies a number of extension 77 headers. These, and the ordering considerations given, were defined 78 based on experience with IPv4 options. They were, however, prescient 79 with respect to their actual use - the IETF community did not know 80 how they would be used. In at least one case, the Hop-by-Hop option, 81 most if not all implementations implement it by punting to a software 82 path. In the words of [RFC7045], 84 The IPv6 Hop-by-Hop Options header SHOULD be processed by 85 intermediate forwarding nodes as described in [RFC2460]. However, 86 it is to be expected that high-performance routers will either 87 ignore it or assign packets containing it to a slow processing 88 path. Designers planning to use a Hop-by-Hop option need to be 89 aware of this likely behaviour. 91 Fernando Gont, in his Observations on IPv6 EH Filtering in the Real 92 World [I-D.ietf-v6ops-ipv6-ehs-in-real-world], and the operational 93 community in IPv6 Operations, consider any punt to a software path to 94 be an attack vector. Hence, IPv6 packets containing the Hop-by-Hop 95 Extension Header (and in some cases, any extension header) get 96 dropped in transit. 98 The subject of this document is implementation approaches to obviate 99 or mitigate the attack vector, and updating the Hop-by-Hop option 100 with respect to current issues. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Handling of options in extension headers 110 Packets containing the Hop-by-Hop Extension Header SHOULD be 111 processed at substantially the same rate as packets that do not. 113 If a hop-by-hop header option is not implemented, or is not in use, 114 in a given system (such as, for example, an interface that is not 115 configured for RSVP receiving an RSVP Alert Option), the option MUST 116 be skipped. 118 If a hop-by-hop header is present in a packet's extension header 119 chain and it is not the first extension header, the packet MUST be 120 discarded by the first system that observes the fact (Section 2.2 of 121 [RFC7045]). This will normally be in the system using the IPv6 122 address in the Destination Address, as [RFC2460] precludes other 123 routers from parsing the header chain. The only obvious exception to 124 that is a router or firewall configured to parse the IPv6 header 125 chain. 127 2.1. Hop-by_hop Options 129 At this writing, there are several defined Hop-by-Hop options: 131 PAD Options: The PAD1 and PADn options [RFC2460] define empty space. 133 Router Alert Option: The IPv6 Router Alert Option [RFC2711] 134 [RFC6398] is intended to force the punting of a datagram to 135 software, in cases in which RSVP or other protocols need that to 136 happen. 138 Jumbo Payload: Carries a length field for a packet whose length 139 exceeds 0xFFFF octets. [RFC2675] 141 RPL Option: The RPL option carries routing information used in a RPL 142 network[RFC6553] 144 Quickstart Option Identifies TCP quick-start configuration, and 145 allows an intermediate router to reduce the configuration 146 parameters as appropriate. [RFC4782] 148 Common Architecture Label IPv6 Security Option: Encodes security 149 labels on packets [RFC5570] 151 SMF Option: Simplified Multicast Forwarding Option[RFC6621] 153 MPL Option: Supports multicast in an RPL network 154 [I-D.ietf-roll-trickle-mcast] 156 DFF Option: Depth-First Forwarding [RFC6971] 158 There are also options that have been defined for the Destination 159 Options header. These are not listed here. 161 While this is not true of older implementations, modern equipment is 162 capable of parsing the Extension Header chain, and can be extended to 163 perform at least a cursory examination of the Hop-by-Hop options. 164 For example, such implementations SHOULD be able to identify and skip 165 the PAD1 and PADn options, and perform more complicated processing 166 only if configured by software to do so. More to the point: it isn't 167 clear what the purpose of the JumboFrame option is if not to be 168 understood by anyone that looks at it. 170 Question asked by a reviewer: "Is this configurable? How will 171 router know that HbH needs to be skipped on one interface and not 172 on others." 174 Answer: the system knows whether RSVP has been configured on an 175 interface. When such configuration is present, it can configure 176 the hardware with what it wants done with the Router Alert. In 177 the absence of such configuration, hardware should be configured 178 to skip the option if found. 180 2.2. Changing options in transit 182 Section 4.2 of [RFC2460] explicitly allows for options that may be 183 updated in transit. It is likely that the original authors intended 184 that to be very simple, such as having the originating end system 185 provide the container, and having intermediate systems update it - 186 perhaps performing some calculation, and in any event storing the 187 resulting value. Examples of such a use might be in [XCP] or [RCP]. 189 As a side comment, the Routing Header, which is an extension header 190 rather than a list of options, is treated similarly; when a system is 191 the destination of a packet and not the last one in the Routing 192 Header's list, it swaps the destination address with the indicated 193 address in the list, and updates the hop count and the list depth 194 accordingly. 196 Such options must be marked appropriately (their option type is of 197 the form XX1XXXXX), and are excluded from checksum calculations in AH 198 and ESP. 200 2.3. Adding headers or options in transit 202 Use cases under current consideration take this a step further: a 203 router or middleware process MAY add an extension header, MAY add an 204 option to the header, which may extend the length of the Hop-by-Hop 205 Extension Header, or MAY process such an option in a manner that 206 extends both the length of the option and the Extension Header 207 containing it. The obvious implication is that other equipment in 208 the network may not understand or implement the new option type. As 209 such, the Option Type value of such an option MUST indicate that it 210 is to be skipped by a system that does not understand it. Since, by 211 definition, it is being updated in transit and not included in any AH 212 or ESP integrity check if present, the Option Type MUST also indicate 213 that it may be updated in transit, and so is excluded from AH and ESP 214 processing. By implication, such an Option Type MUST be of the form 215 001XXXXX. 217 2.4. Interactions with the Security Extension Header 219 The interactions with the IP Authentication Header [RFC4302] and IP 220 Encapsulating Security Payload (ESP) [RFC4303], as in the case of 221 existing option uses, is minimally defined. AH and ESP call for the 222 exclusion of mutable data in their calculations by zeroing it out 223 prior to performing the integrity check calculation. However, in the 224 case that network operation has changed the length of the option or 225 the extension header, that may still cause the integrity check to 226 fail. Specifications that define such options SHOULD consider the 227 implications of this for AH and ESP. An option whose insertion would 228 affect the integrity check MUST be removed prior to the integrity 229 check, and as a result the packet restored to its state as originally 230 sent. 232 3. Interoperation with RFC 2460 234 There are four possible modes of interaction with routers that don't 235 implement the Hop-By-Hop Option in the fast path: 237 1. Presume that they cannot handle the Hop-By-Hop option at close to 238 wire speed, and that's OK. 240 2. Presume that they will drop traffic containing Hop-By-Hop 241 options. 243 3. Presume that they can handle the Hop-By-Hop option at or close to 244 wire speed, and are configured to do so. 246 4. Presume that they don't exist, perhaps because older routers are 247 configured to ignore all Hop-by-Hop options. 249 If the first model actually works in a given network, it may be 250 acceptable in that domain. It is not a model that will work in the 251 general Internet, however. 253 The second model (which is most probable at this writing) is a 254 description of the general Internet in 2015. 256 The third and fourth models, if applicable in a given context, are 257 what one might hope for. Vendors are in a position to either have an 258 option to ignore the Hop-By-Hop header in older equipment, or add 259 such an option in upgraded software (fourth model). New equipment is 260 expected to follow the third model by implementing the 261 recommendations in Section 2. 263 4. IANA Considerations 265 This memo asks the IANA for no new parameters. 267 5. Security Considerations 269 In general, modification of a datagram in transit is considered very 270 closely from the viewpoint of the End-to-End Principle, which in this 271 context may be summarized as "the network should do nothing that is 272 of concern to the communicating applications or introduces 273 operational issues." The concept of changing the length of an 274 Extension Header or an option contained within it (Section 2.3) is of 275 concern in that context. The obvious concern is around the 276 interaction with AH or ESP, and a less obvious concern relates to 277 Path MTU, which might change if the size of an underlying header 278 changes. Section 2.4 is intended to mitigate that issue. However, 279 some ramifications, such as with Path MTU, may not be completely 280 solvable in the general Internet, but require use cases to be 281 confined to a network or set of consenting networks. 283 6. Privacy Considerations 285 Data formats in this memo reveal no personally identifying 286 information. 288 7. Acknowledgements 290 This note grew out of a discussion among the author, Ole Troan, Mark 291 Townsley, Frank Brockners, and Shwetha Bhandari, and benefited from 292 comments by Dennis Ferguson, Brian Carpenter, Panos Kampanakis, 293 JINMEI Tatuya, and Joe Touch. 295 8. References 297 8.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 305 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 306 December 1998, . 308 8.2. Informative References 310 [I-D.ietf-roll-trickle-mcast] 311 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 312 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 313 mcast-12 (work in progress), June 2015. 315 [I-D.ietf-v6ops-ipv6-ehs-in-real-world] 316 Gont, F., Linkova, J., Chown, T., and S. LIU, 317 "Observations on the Dropping of Packets with IPv6 318 Extension Headers in the Real World", draft-ietf-v6ops- 319 ipv6-ehs-in-real-world-01 (work in progress), October 320 2015. 322 [RCP] Dukkipati, N., "Rate Control Protocol (RCP): Congestion 323 control to make flows complete quickly", Stanford 324 University , 2006. 326 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 327 RFC 2675, DOI 10.17487/RFC2675, August 1999, 328 . 330 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 331 RFC 2711, DOI 10.17487/RFC2711, October 1999, 332 . 334 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 335 DOI 10.17487/RFC4302, December 2005, 336 . 338 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 339 RFC 4303, DOI 10.17487/RFC4303, December 2005, 340 . 342 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 343 Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782, 344 January 2007, . 346 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 347 Architecture Label IPv6 Security Option (CALIPSO)", 348 RFC 5570, DOI 10.17487/RFC5570, July 2009, 349 . 351 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 352 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 353 2011, . 355 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 356 Power and Lossy Networks (RPL) Option for Carrying RPL 357 Information in Data-Plane Datagrams", RFC 6553, 358 DOI 10.17487/RFC6553, March 2012, 359 . 361 [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", 362 RFC 6621, DOI 10.17487/RFC6621, May 2012, 363 . 365 [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. 366 Cespedes, "Depth-First Forwarding (DFF) in Unreliable 367 Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013, 368 . 370 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 371 of IPv6 Extension Headers", RFC 7045, 372 DOI 10.17487/RFC7045, December 2013, 373 . 375 [XCP] Katabi, D., Handley, M., and C. Rohrs, "Congestion control 376 for high bandwidth-delay product networks", SIGCOMM 377 Symposium proceedings on Communications architectures and 378 protocols , 2002. 380 Appendix A. Change Log 382 Initial Version: June 2015 384 01 Version: June 2015, responding to list discussion 386 02 Version: July 2015, discussed at IETF 93 388 03 Version: October 2015 390 Author's Address 392 Fred Baker 393 Cisco Systems 394 Santa Barbara, California 93117 395 USA 397 Email: fred@cisco.com