idnits 2.17.1 draft-ietf-6man-ext-transmit-05.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 RFC2780, but the abstract doesn't seem to directly say this. It does mention RFC2780 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 (October 17, 2013) is 3843 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 (-09) exists of draft-ietf-6man-oversized-header-chain-08 == Outdated reference: A later version (-02) exists of draft-taylor-v6ops-fragdrop-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Updates: 2460, 2780 (if approved) S. Jiang 5 Intended status: Standards Track Huawei Technologies Co., Ltd 6 Expires: April 20, 2014 October 17, 2013 8 Transmission and Processing of IPv6 Extension Headers 9 draft-ietf-6man-ext-transmit-05 11 Abstract 13 Various IPv6 extension headers have been standardised since the IPv6 14 standard was first published. This document updates RFC 2460 to 15 clarify how intermediate nodes should deal with such extension 16 headers and with any that are defined in future. It also specifies 17 how extension headers should be registered by IANA, with a 18 corresponding minor update to RFC 2780. 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 http://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 April 20, 2014. 37 Copyright Notice 39 Copyright (c) 2013 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 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Requirement to Transmit Extension Headers . . . . . . . . . . 4 57 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5 58 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 7.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction and Problem Statement 70 In IPv6, an extension header is any header that follows the initial 71 40 bytes of the packet and precedes the upper layer header (which 72 might be a transport header, an ICMPv6 header, or a notional "No Next 73 Header"). 75 An initial set of IPv6 extension headers was defined by [RFC2460], 76 which also described how they should be handled by intermediate 77 nodes, with the exception of the hop-by-hop options header: 79 "...extension headers are not examined or processed 80 by any node along a packet's delivery path, until the packet reaches 81 the node (or each of the set of nodes, in the case of multicast) 82 identified in the Destination Address field of the IPv6 header." 84 This provision meant that forwarding nodes should be completely 85 transparent to extension headers. There was no provision for 86 forwarding nodes to modify them, remove them, insert them, or use 87 them to affect forwarding behaviour. Thus, new extension headers 88 could be introduced progressively, used only by hosts that have been 89 updated to create and interpret them [RFC6564]. The extension header 90 mechanism is an important part of the IPv6 architecture, and several 91 new extension headers have been standardised since RFC 2460. 93 Today, IPv6 packets are often forwarded not only on the basis of 94 their first 40 bytes by straightforward IP routing. Some routers, 95 and a variety of intermediate nodes often referred to as middleboxes, 96 such as firewalls, load balancers, or packet classifiers, might 97 inspect other parts of each packet. Indeed, such middlebox functions 98 are often embedded in routers. However, experience has shown that as 99 a result, the network is not transparent to IPv6 extension headers. 100 Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and 101 process the entire IPv6 packet before making a decision to either 102 forward or discard the packet. This means that they need to traverse 103 the chain of extension headers, if present, until they find the 104 transport header (or an encrypted payload). Unfortunately, because 105 not all IPv6 extension headers follow a uniform TLV format, this 106 process is clumsy and requires knowledge of each extension header's 107 format. A separate problem is that the header chain may even be 108 fragmented [I-D.ietf-6man-oversized-header-chain]. 110 The process is potentially slow as well as clumsy, possibly 111 precluding its use in nodes attempting to process packets at line 112 speed. The present document does not intend to solve this problem, 113 which is caused by the fundamental architecture of IPv6 extension 114 headers. This document focuses on clarifying how the header chain 115 should be handled in the current IPv6 architecture. 117 If they encounter an unrecognised extension header type, some 118 firewalls treat the packet as suspect and drop it. Unfortunately, it 119 is an established fact that several widely used firewalls do not 120 recognise some or all of the extension headers standardised since RFC 121 2460. It has also been observed that certain firewalls do not even 122 handle all the extension headers standardised in RFC 2460, including 123 the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental 124 problems of end-to-end connectivity. This applies in particular to 125 firewalls that attempt to inspect packets at very high speed, since 126 they cannot take the time to reassemble fragmented packets, 127 especially when under a denial of service attack. 129 Other types of middlebox, such as load balancers or packet 130 classifiers, might also fail in the presence of extension headers 131 that they do not recognise. 133 A contributory factor to this problem is that, because extension 134 headers are numbered out of the existing IP Protocol Number space, 135 there is no collected list of them. For this reason, it is hard for 136 an implementor to quickly identify the full set of standard extension 137 headers. An implementor who consults only RFC 2460 will miss all 138 extension headers defined subsequently. 140 This combination of circumstances creates a "Catch-22" situation 141 [Heller] for the deployment of any newly standardised extension 142 header except for local use. It cannot be widely deployed, because 143 existing middleboxes will drop it on many paths through the Internet. 145 However, most middleboxes will not be updated to allow the new header 146 to pass until it has been proved safe and useful on the open 147 Internet, which is impossible until the middleboxes have been 148 updated. 150 The uniform TLV format now defined for extension headers [RFC6564] 151 will improve the situation, but only for future extensions. Some 152 tricky and potentially malicious cases will be avoided by forbidding 153 very long chains of extension headers that need to be fragmented 154 [I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns 155 that stateless firewalls cannot locate a complete header chain as 156 required by the present document. 158 However, these changes are insufficient to correct the underlying 159 problem. The present document clarifies that the above requirement 160 from RFC 2460 applies to all types of nodes that forward IPv6 packets 161 and to all extension headers standardised now and in the future. It 162 also requests IANA to create a subsidiary registry that clearly 163 identifies extension header types, and updates RFC 2780 accordingly. 164 Fundamental changes to the IPv6 extension header architecture are out 165 of scope for this document. 167 Also, Hop-by-Hop options are not handled by many high speed routers, 168 or are processed only on a slow path. This document also updates the 169 requirements for processing the Hop-by-Hop options header to make 170 them more realistic. 172 1.1. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 In the remainder of this document, the term "forwarding node" refers 179 to any router, firewall, load balancer, prefix translator, or any 180 other device or middlebox that forwards IPv6 packets with or without 181 examining the packet in any way. 183 In this document "standard" IPv6 extension headers are those 184 specified in detail by IETF standards actions. "Experimental" 185 extension headers include those defined by any Experimental RFC, and 186 the header values 253 and 254 defined by [RFC3692] and [RFC4727] when 187 used as experimental extension headers. "Defined" extension headers 188 are the "standard" extension headers plus the "experimental" ones. 190 2. Requirement to Transmit Extension Headers 191 2.1. All Extension Headers 193 As mentioned above, forwarding nodes that discard packets containing 194 extension headers are known to cause connectivity failures and 195 deployment problems. Therefore, it is important that forwarding 196 nodes that inspect IPv6 headers can parse all defined extension 197 headers and deal with them appropriately, as specified in this 198 section. 200 Any forwarding node along an IPv6 packet's path, which forwards the 201 packet for any reason, SHOULD do so regardless of any extension 202 headers that are present, as required by RFC 2460. Exceptionally, if 203 a forwarding node is designed to examine extension headers for any 204 reason, such as firewalling, it MUST recognise and deal appropriately 205 with all standard IPv6 extension header types and SHOULD recognise 206 and deal appropriately with experimental IPv6 extension header types. 207 The list of standard and experimental extension header types is 208 maintained by IANA (see Section 4) and implementors are advised to 209 check this list regularly for updates. 211 RFC 2460 requires destination hosts to discard packets containing 212 unrecognised extension headers. However, intermediate forwarding 213 nodes SHOULD NOT do this, since that might cause them to 214 inadvertently discard traffic using a recently standardised extension 215 header, not yet recognised by the intermediate node. The exceptions 216 to this rule are discussed next. 218 If a forwarding node discards a packet containing a standard IPv6 219 extension header, it MUST be the result of a configurable policy, and 220 not just the result of a failure to recognise such a header. This 221 means that the discard policy for each standard type of extension 222 header MUST be individually configurable. The default configuration 223 SHOULD allow all standard extension headers. 225 Experimental IPv6 extension headers SHOULD be treated in the same way 226 as standard extension headers, including an individually configurable 227 discard policy. However, the default configuration MAY drop 228 experimental extension headers. 230 Forwarding nodes MUST be configurable to allow packets containing 231 unrecognised extension headers, but the default configuration MAY 232 drop such packets. 234 The IPv6 Routing Header Types 0 and 1 have been deprecated [RFC5095]. 235 However, this does not mean that the IPv6 Routing Header can be 236 unconditionally dropped by forwarding nodes. Packets containing 237 standardised and undeprecated Routing Headers SHOULD be forwarded by 238 default. At the time of writing, these include Type 2 [RFC6275], 239 Type 3 [RFC6554], and the experimental Routing Header Types 253 and 240 254 [RFC4727]. Others may be defined in future. 242 2.2. Hop-by-Hop Options 244 The IPv6 Hop-by-Hop Options header SHOULD be processed by 245 intermediate forwarding nodes as described in [RFC2460]. However, it 246 is to be expected that high performance routers will either ignore 247 it, or assign packets containing it to a slow processing path. 248 Designers planning to use a Hop-by-Hop option need to be aware of 249 this likely behaviour. 251 As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options 252 header, if present, must be first. 254 3. Security Considerations 256 Forwarding nodes that operate as firewalls MUST conform to the 257 requirements in the previous section in order to respect the IPv6 258 extension header architecture. In particular, packets containing 259 standard extension headers are only to be discarded as a result of an 260 intentionally configured policy. 262 These changes do not affect a firewall's ability to filter out 263 traffic containing unwanted or suspect extension headers, if 264 configured to do so. However, the changes do require firewalls to be 265 capable of permitting any or all extension headers, if configured to 266 do so. The default configurations are intended to allow normal use 267 of any standard extension header, avoiding the connectivity issues 268 described in Section 1 and Section 2.1. 270 As noted above, the default configuration might drop packets 271 containing experimental extension headers. There is no header length 272 field in an IPv6 header, and header types 253 and 254 might be used 273 either for experimental extension headers or for experimental payload 274 types. Therefore, there is no generic algorithm by which a firewall 275 can distinguish these two cases and analyze the remainder of the 276 packet. This should be considered when deciding on the appropriate 277 default action for header types 253 and 254. 279 When new extension headers are standardised in the future, those 280 implementing and configuring forwarding nodes, including firewalls, 281 will need to take them into account. A newly defined header will 282 exercise new code paths in a host that does recognise it, so caution 283 may be required. Additional security issues with experimental values 284 or new extension headers are to be found in [RFC4727] and [RFC6564]. 285 As a result, it is to be expected that the deployment process will be 286 slow and will depend on satisfactory operational experience. Until 287 deployment is complete, the new extension will fail in some parts of 288 the Internet. This aspect needs to be considered when deciding to 289 standardise a new extension. Specific security considerations for 290 each new extension should be documented in the document that defines 291 it. 293 4. IANA Considerations 295 IANA is requested to clearly mark in the Assigned Internet Protocol 296 Numbers registry those values which are also IPv6 Extension Header 297 types defined by an IETF Standards Action or IESG Approval (see list 298 below), for example by adding an extra column title "IPv6 Extension 299 Header" to indicate this. This will also apply to any IPv6 Extension 300 Header types defined in the future. 302 Additionally, IANA is requested to close the existing empty IPv6 Next 303 Header Types registry to new entries, and redirect its users to a new 304 IPv6 Extension Header Types registry. This will contain only those 305 protocol numbers which are also marked as IPv6 Extension Header types 306 in the Assigned Internet Protocol Numbers registry. Experimental 307 values will be marked as such. The initial list will be as follows: 309 o 0, Hop-by-Hop Options, [RFC2460] 311 o 43, Routing, [RFC2460], [RFC5095] 313 o 44, Fragment, [RFC2460] 315 o 50, Encapsulating Security Payload, [RFC4303] 317 o 51, Authentication, [RFC4302] 319 o 60, Destination Options, [RFC2460] 321 o 135, MIPv6, [RFC6275] 323 o 139, experimental use, HIP, [RFC5201] 325 o 140, shim6, [RFC5533] 327 o 253, experimental use, [RFC3692], [RFC4727] 329 o 254, experimental use, [RFC3692], [RFC4727] 331 This list excludes type 59, No Next Header, [RFC2460], which is not 332 an extension header as such. 334 The references to the IPv6 Next Header field in [RFC2780] are to be 335 interpreted as also applying to the IPv6 Extension Header field and 336 the IPv6 Extension Header Types registry will be managed accordingly. 338 5. Acknowledgements 340 This document was triggered by mailing list discussions including 341 John Leslie, Stefan Marksteiner and others. Valuable comments and 342 contributions were made by Dominique Barthel, Tim Chown, Lorenzo 343 Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh 344 Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan 345 Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others. 347 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 348 University during part of this work. 350 This document was produced using the xml2rfc tool [RFC2629]. 352 6. Change log [RFC Editor: Please remove] 354 draft-ietf-6man-ext-transmit-05: updates following IESG comments, 355 2013-10-17. 357 draft-ietf-6man-ext-transmit-04: updates following IETF Last Call, 358 normative requirements clarified, IANA considerations clarified, 359 security consuderations expanded, 2013-09-26. 361 draft-ietf-6man-ext-transmit-03: added details for experimental 362 values, various clarifications and minor corrections, 2013-08-22. 364 draft-ietf-6man-ext-transmit-02: explicit mention of header types 253 365 and 254, editorial fixes, 2013-08-06. 367 draft-ietf-6man-ext-transmit-01: tuned use of normative language, 368 clarified that only standardised extensions are covered (hence 369 excluding HIP), 2013-05-29. 371 draft-ietf-6man-ext-transmit-00: first WG version, more 372 clarifications, 2013-03-26. 374 draft-carpenter-6man-ext-transmit-02: clarifications following WG 375 comments, recalibrated firewall requirements, 2013-02-22. 377 draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify 378 scope and impact on firewalls, discuss line-speed processing and lack 379 of uniform TLV format, added references, restructured IANA 380 considerations, 2012-11-13. 382 draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14. 384 7. References 386 7.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 392 (IPv6) Specification", RFC 2460, December 1998. 394 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 395 Values In the Internet Protocol and Related Headers", BCP 396 37, RFC 2780, March 2000. 398 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 399 Considered Useful", BCP 82, RFC 3692, January 2004. 401 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 402 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 404 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 405 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 406 RFC 6564, April 2012. 408 7.2. Informative References 410 [Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. 412 [I-D.ietf-6man-oversized-header-chain] 413 Gont, F., Manral, V., and R. Bonica, "Implications of 414 Oversized IPv6 Header Chains", draft-ietf-6man-oversized- 415 header-chain-08 (work in progress), October 2013. 417 [I-D.taylor-v6ops-fragdrop] 418 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 419 M., and T. Taylor, "Why Operators Filter Fragments and 420 What It Implies", draft-taylor-v6ops-fragdrop-01 (work in 421 progress), June 2013. 423 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 424 June 1999. 426 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 427 2005. 429 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 430 4303, December 2005. 432 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 433 of Type 0 Routing Headers in IPv6", RFC 5095, December 434 2007. 436 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 437 "Host Identity Protocol", RFC 5201, April 2008. 439 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 440 Shim Protocol for IPv6", RFC 5533, June 2009. 442 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 443 in IPv6", RFC 6275, July 2011. 445 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 446 Routing Header for Source Routes with the Routing Protocol 447 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 448 2012. 450 Authors' Addresses 452 Brian Carpenter 453 Department of Computer Science 454 University of Auckland 455 PB 92019 456 Auckland 1142 457 New Zealand 459 Email: brian.e.carpenter@gmail.com 461 Sheng Jiang 462 Huawei Technologies Co., Ltd 463 Q14, Huawei Campus 464 No.156 Beiqing Road 465 Hai-Dian District, Beijing 100095 466 P.R. China 468 Email: jiangsheng@huawei.com