idnits 2.17.1 draft-ietf-6man-ext-transmit-01.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 (May 29, 2013) is 3977 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) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) == Outdated reference: A later version (-09) exists of draft-ietf-6man-oversized-header-chain-02 == Outdated reference: A later version (-02) exists of draft-taylor-v6ops-fragdrop-00 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man B. E. 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: November 30, 2013 May 29, 2013 8 Transmission of IPv6 Extension Headers 9 draft-ietf-6man-ext-transmit-01 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 November 30, 2013. 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 . . . . . . . . . . . . . . . . . . 4 58 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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. The extension header mechanism 90 is an important part of the IPv6 architecture, and several new 91 extension headers have been standardised since RFC 2460. 93 Today, packets are often forwarded not only by straightforward IP 94 routers, but also by a variety of intermediate nodes, often referred 95 to as middleboxes, such as firewalls, load balancers, or packet 96 classifiers. Unfortunately, experience has showed that as a result, 97 the network is not transparent to IPv6 extension headers. Contrary 98 to Section 4 of RFC 2460, middleboxes sometimes examine and process 99 the entire IPv6 packet before making a decision to either forward or 100 discard the packet. This means that they need to traverse the chain 101 of extension headers, if present, until they find the transport 102 header (or an encrypted payload). Unfortunately, because not all 103 IPv6 extension headers follow a uniform TLV format, this process is 104 clumsy and requires knowledge of each extension header's format. 106 The process is potentially slow as well as clumsy, possibly 107 precluding its use in nodes attempting to process packets at line 108 speed. The present document does not intend to solve this problem, 109 which is caused by the fundamental architecture of IPv6 extension 110 headers. This document focuses on clarifying how the header chain 111 should be traversed in the current IPv6 architecture. 113 If they encounter an unrecognised extension header type, some 114 firewalls treat the packet as suspect and drop it. Unfortunately, it 115 is an established fact that several widely used firewalls do not 116 recognise some or all of the extension headers standardised since RFC 117 2460. It has also been observed that certain firewalls do not even 118 handle all the extension headers standardised in RFC 2460, including 119 the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental 120 problems of connectivity. This applies in particular to firewalls 121 that attempt to inspect packets statelessly at very high speed, since 122 they cannot take the time to reassemble fragmented packets, 123 especially when under a denial of service attack. 125 Other types of middlebox, such as load balancers or packet 126 classifiers, might also fail in the presence of extension headers 127 that they do not recognise. 129 A contributory factor to this problem is that, because extension 130 headers are numbered out of the existing IP Protocol Number space, 131 there is no collected list of them. For this reason, it is hard for 132 an implementor to quickly identify the full set of standard extension 133 headers. An implementor who consults only RFC 2460 will miss all 134 extension headers defined subsequently. 136 This combination of circumstances creates a "Catch-22" situation 137 [Heller] for the deployment of any newly standardised extension 138 header except for local use. It cannot be widely deployed, because 139 existing middleboxes will render large parts of the Internet opaque 140 to it. However, most middleboxes will not be updated to allow the 141 new header to pass until it has been proved safe and useful on the 142 open Internet, which is impossible until the middleboxes have been 143 updated. 145 The uniform TLV format now defined for extension headers [RFC6564] 146 will improve the situation, but only for future extensions. Some 147 tricky and potentially malicious cases will be avoided by forbidding 148 very long chains of extension headers that need to be fragmented 149 [I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns 150 that stateless firewalls cannot handle a complete header chain as 151 required by the present document. 153 However, these changes are insufficient to correct the underlying 154 problem. The present document clarifies that the above requirement 155 from RFC 2460 applies to all types of node that forward IPv6 packets 156 and to all extension headers standardised now and in the future. It 157 also requests IANA to create a subsidiary registry that clearly 158 identifies extension header types, and updates RFC 2780 accordingly. 159 Fundamental changes to the IPv6 extension header architecture are out 160 of scope for this document. 162 Also, Hop-by-Hop options are not handled by many high speed routers, 163 or are processed only on a slow path. This document also updates the 164 requirements for processing the Hop-by-Hop options header to make 165 them more realistic. 167 1.1. Terminology 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 In the remainder of this document, the term "forwarding node" refers 174 to any router, firewall, load balancer, prefix translator, or any 175 other device or middlebox that forwards IPv6 packets with or without 176 examining the packet in any way. 178 2. Requirement to Transmit Extension Headers 180 2.1. All Extension Headers 182 Any forwarding node along an IPv6 packet's path, which forwards it 183 for any reason, SHOULD do so regardless of any extension headers that 184 are present, as required by RFC 2460. Exceptionally, if this node is 185 designed to examine extension headers for any reason, such as 186 firewalling, it MUST recognise and deal appropriately with all 187 standard IPv6 extension header types. The list of standard extension 188 header types is maintained by IANA (see Section 4) and implementors 189 are advised to check this list regularly for updates. 191 RFC 2460 requires destination hosts to discard packets containing 192 unrecognised extension headers. However, intermediate forwarding 193 nodes SHOULD NOT do this by default, since that might cause them to 194 inadvertently discard traffic using a recently standardised extension 195 header, not yet recognised by the intermediate node. The only 196 exceptions to this rule are discussed below. 198 As mentioned above, forwarding nodes that discard packets containing 199 extension headers are known to cause connectivity failures and 200 deployment problems. Therefore, it is important that forwarding 201 nodes that inspect IPv6 extension headers can parse all standard 202 headers and are able to behave according to the above requirements. 203 If a forwarding node discards a packet containing a standard IPv6 204 extension header, it MUST be the result of a configurable policy, and 205 not just the result of a failure to recognise such a header. This 206 means that the discard policy for each standard type of extension 207 header MUST be individually configurable. The default configuration 208 SHOULD allow all standard extension headers. Forwarding nodes MUST 209 be configurable to allow packets containing unrecognised extension 210 headers, and such packets MAY be dropped by default. 212 The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD 213 NOT be used. However, as specified in [RFC5095], this does not mean 214 that the IPv6 Routing Header can be unconditionally dropped by 215 forwarding nodes. Packets containing undeprecated Routing Headers 216 SHOULD be forwarded by default. At the time of writing, these 217 include Type 2 [RFC6275], Type 3 [RFC6554], and Types 253 and 254 218 [RFC4727]. Others may be defined in future. 220 2.2. Hop-by-Hop Options 222 The IPv6 Hop-by-Hop Options header SHOULD be processed by 223 intermediate forwarding nodes as described in [RFC2460]. However, it 224 is to be expected that high performance routers will either ignore 225 it, or assign packets containing it to a slow processing path. 226 Designers planning to use a Hop-by-Hop option need to be aware of 227 this likely behaviour. 229 As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options 230 header, if present, must be first. 232 3. Security Considerations 234 Forwarding nodes that operate as firewalls MUST conform to the 235 requirements in the previous section in order to respect the IPv6 236 extension header architecture. In particular, packets containing 237 standard extension headers are only to be discarded as a result of a 238 configurable policy. 240 When new extension headers are standardised in the future, those 241 implementing and configuring forwarding nodes, including firewalls, 242 will need to take account of them. A newly defined header will 243 exercise new code paths in a host that does recognise it, so caution 244 may be required. It is therefore to be expected that the deployment 245 process will be slow and will depend on satisfactory operational 246 experience. Until it is complete, the new extension will fail in 247 some parts of the Internet. This aspect needs to be considered when 248 deciding to standardise a new extension. Specific security 249 considerations for each new extension should be documented in the 250 document that defines it. 252 4. IANA Considerations 254 IANA is requested to clearly mark in the Assigned Internet Protocol 255 Numbers registry those values which are also IPv6 Extension Header 256 types defined by an IETF standards action, for example by adding an 257 extra column to indicate this. This will also apply to any IPv6 258 Extension Header types standardised in the future. 260 Additionally, IANA is requested to replace the existing empty IPv6 261 Next Header Types registry by an IPv6 Extension Header Types 262 registry. It will contain only those protocol numbers which are also 263 marked as IPv6 Extension Header types in the Assigned Internet 264 Protocol Numbers registry and were defined by an IETF standards 265 action. The initial list will be as follows: 267 o 0, Hop-by-Hop Options, [RFC2460] 269 o 43, Routing, [RFC2460], [RFC5095] 271 o 44, Fragment, [RFC2460] 273 o 50, Encapsulating Security Payload, [RFC4303] 275 o 51, Authentication, [RFC4302] 277 o 60, Destination Options, [RFC2460] 279 o 135, MIPv6, [RFC6275] 281 o 140, shim6, [RFC5533] 283 This list excludes both type 59, No Next Header, [RFC2460], which is 284 not an extension header as such, and type 139, HIP, [RFC5201], which 285 is experimental. 287 The references to the IPv6 Next Header field in [RFC2780] are to be 288 interpreted as also applying to the IPv6 Extension Header field. 290 5. Acknowledgements 292 This document was triggered by mailing list discussions including 293 John Leslie, Stefan Marksteiner and others. Valuable comments and 294 contributions were made by Dominique Barthel, Tim Chown, Lorenzo 295 Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh 296 Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch, and 297 others. 299 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 300 University during part of this work. 302 This document was produced using the xml2rfc tool [RFC2629]. 304 6. Change log [RFC Editor: Please remove] 306 draft-ietf-6man-ext-transmit-01: tuned use of normative language, 307 clarified that only standardised extensions are covered (hence 308 excluding HIP), 2013-05-29. 310 draft-ietf-6man-ext-transmit-00: first WG version, more 311 clarifications, 2013-03-26. 313 draft-carpenter-6man-ext-transmit-02: clarifications following WG 314 comments, recalibrated firewall requirements, 2013-02-22. 316 draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify 317 scope and impact on firewalls, discuss line-speed processing and lack 318 of uniform TLV format, added references, restructured IANA 319 considerations, 2012-11-13. 321 draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14. 323 7. References 325 7.1. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 331 6 (IPv6) Specification", RFC 2460, December 1998. 333 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 334 Values In the Internet Protocol and Related Headers", BCP 335 37, RFC 2780, March 2000. 337 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 338 2005. 340 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 341 4303, December 2005. 343 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 344 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 346 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 347 of Type 0 Routing Headers in IPv6", RFC 5095, December 348 2007. 350 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 351 "Host Identity Protocol", RFC 5201, April 2008. 353 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 354 Shim Protocol for IPv6", RFC 5533, June 2009. 356 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 357 in IPv6", RFC 6275, July 2011. 359 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 360 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 361 RFC 6564, April 2012. 363 7.2. Informative References 365 [Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. 367 [I-D.ietf-6man-oversized-header-chain] 368 Gont, F. and V. Manral, "Security and Interoperability 369 Implications of Oversized IPv6 Header Chains", draft-ietf- 370 6man-oversized-header-chain-02 (work in progress), 371 November 2012. 373 [I-D.taylor-v6ops-fragdrop] 374 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 375 M., and T. Taylor, "Why Operators Filter Fragments and 376 What It Implies", draft-taylor-v6ops-fragdrop-00 (work in 377 progress), October 2012. 379 [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, 380 June 1999. 382 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 383 Routing Header for Source Routes with the Routing Protocol 384 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 385 2012. 387 Authors' Addresses 389 Brian Carpenter 390 Department of Computer Science 391 University of Auckland 392 PB 92019 393 Auckland 1142 394 New Zealand 396 Email: brian.e.carpenter@gmail.com 398 Sheng Jiang 399 Huawei Technologies Co., Ltd 400 Q14, Huawei Campus 401 No.156 Beiqing Road 402 Hai-Dian District, Beijing 100095 403 P.R. China 405 Email: jiangsheng@huawei.com