idnits 2.17.1 draft-carpenter-6man-ext-transmit-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- 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 (February 22, 2013) is 4073 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: August 26, 2013 February 22, 2013 8 Transmission of IPv6 Extension Headers 9 draft-carpenter-6man-ext-transmit-02 11 Abstract 13 Various IPv6 extension headers have been defined 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 August 26, 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 . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2. Requirement to Transmit Extension Headers . . . . . . . . . . . 5 57 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . . 5 58 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . . 6 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 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 allowed for the addition of new extension headers, 85 since it means that forwarding nodes should be completely transparent 86 to them. Thus, new extension headers could be introduced 87 progressively, used only by hosts that have been updated to create 88 and interpret them. The extension header mechanism is an important 89 part of the IPv6 architecture, and several new extension headers have 90 been defined since RFC 2460. 92 Unfortunately, experience has showed that the network is not 93 transparent to these headers. The main reason for this is that by 94 design, some firewalls attempt to inspect the transport header or 95 payload. This means that they need to traverse the chain of 96 extension headers, if present, until they find the transport header 97 (or an encrypted payload). Unfortunately, because not all IPv6 98 extension headers follow a uniform TLV format, this process is clumsy 99 and requires knowledge of each extension header's format. 101 The process is potentially slow as well as clumsy, possibly 102 precluding its use in nodes attempting to process packets at line 103 speed. The present document does not intend to solve this problem, 104 which is caused by the fundamental architecture of IPv6 extension 105 headers. This document focuses on clarifying how the header chain 106 should be traversed in the current IPv6 architecture. 108 If they encounter an unrecognised extension header type, some 109 firewalls treat the packet as suspect and drop it. Unfortunately, it 110 is an established fact that several widely used firewalls do not 111 recognise some or all of the extension headers defined since RFC 112 2460. It has also been observed that certain firewalls do not even 113 handle all the extension headers in RFC 2460, including the fragment 114 header [I-D.taylor-v6ops-fragdrop], causing fundamental problems of 115 connectivity. This applies in particular to firewalls that attempt 116 to inspect packets statelessly at very high speed, since they cannot 117 take the time to reassemble fragmented packets, especially when under 118 a denial of service attack. 120 Other types of middlebox, such as load balancers or packet 121 classifiers, might also fail in the presence of extension headers 122 that they do not recognise. 124 A contributory factor to this problem is that, because extension 125 headers are numbered out of the existing IP Protocol Number space, 126 there is no collected list of them. For this reason, it is hard for 127 an implementor to quickly identify the full set of defined extension 128 headers. An implementor who consults only RFC 2460 will miss all 129 extension headers defined subsequently. 131 This combination of circumstances creates a "Catch-22" situation 132 [Heller] for the deployment of any newly designed extension header. 133 It cannot be widely deployed, because existing firewalls will render 134 large parts of the Internet opaque to it. However, most firewalls 135 will not be updated to allow the new header to pass until it has been 136 proved safe and useful on the open Internet, which is impossible 137 until the firewalls have been updated. 139 The uniform TLV format now defined for extension headers [RFC6564] 140 will improve the situation, but only for future extensions. Some 141 tricky and potentially malicious cases will be avoided by forbidding 142 very long chains of extension headers that need to be fragmented 143 [I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns 144 that stateless firewalls cannot handle a complete header chain as 145 required by the present document. 147 However, these changes are insufficient to correct the underlying 148 problem. The present document clarifies that the above requirement 149 from RFC 2460 applies to all types of node that forward IPv6 packets 150 and to all extension headers defined now and in the future. It also 151 requests IANA to create a subsidiary registry that clearly identifies 152 extension header types, and updates RFC 2780 accordingly. 153 Fundamental changes to the IPv6 extension header architecture are out 154 of scope for this document. 156 Also, Hop-by-Hop options are not handled by many high speed routers, 157 or are processed only on a slow path. This document also updates the 158 requirements for processing the Hop-by-Hop options header to make 159 them more realistic. 161 1.1. Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 2. Requirement to Transmit Extension Headers 169 2.1. All Extension Headers 171 Any node along an IPv6 packet's path, which forwards it for any 172 reason, SHOULD do so regardless of any extension headers that are 173 present, as described in RFC 2460. Exceptionally, if this node is 174 designed to examine extension headers for any reason, such as 175 firewalling, it MUST recognise and deal appropriately with all 176 defined IPv6 extension header types. The list of currently defined 177 extension header types is maintained by IANA (see Section 4) and 178 implementors are advised to check this list regularly for updates. 180 RFC 2460 requires destination hosts to discard packets containing 181 unrecognised extension headers. However, intermediate forwarding 182 nodes MUST NOT do this by default, since that might cause them to 183 inadvertently discard traffic using a recently defined extension 184 header, not yet recognised by the intermediate node. 186 As mentioned above, firewalls that discard packets containing 187 extension headers are known to cause connectivity failures and 188 deployment problems. Therefore, it is important that firewalls can 189 parse all defined IPv6 extension headers and are able to behave 190 according to the above requirements. If a firewall discards a packet 191 containing a defined IPv6 extension header, it MUST be the result of 192 a configurable firewall policy, and not just the result of a failure 193 to recognise such a header. This means that the discard policy for 194 each defined type of extension header MUST be individually 195 configurable. The default configuration SHOULD allow all defined 196 extension headers. Firewalls MUST be configurable to allow packets 197 containing unrecognised extension headers, but such packets MUST be 198 dropped by default. 200 The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD 201 NOT be used. However, as specified in [RFC5095], this does not mean 202 that the IPv6 Routing Header can be unconditionally dropped by 203 forwarding nodes. Packets containing undeprecated Routing Headers 204 SHOULD be forwarded by default. At the time of writing, these include 205 Type 2 [RFC6275], Type 3 [RFC6554], and Types 253 and 254 [RFC4727]. 206 Others may be defined in future. 208 2.2. Hop-by-Hop Options 210 The IPv6 Hop-by-Hop Options header SHOULD be processed by 211 intermediate nodes as described in [RFC2460]. However, it is to be 212 expected that high performance routers will either ignore it, or 213 assign packets containing it to a slow processing path. Designers 214 planning to use a Hop-by-Hop option need to be aware of this likely 215 behaviour. 217 As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options 218 header, if present, must be first. 220 3. Security Considerations 222 Firewall devices MUST conform to the requirements in the previous 223 section in order to respect the IPv6 extension header architecture. 224 In particular, packets containing specific extension headers are only 225 to be discarded as a result of a configurable policy. 227 When new extension headers are defined in the future, those 228 implementing and configuring firewalls will need to take account of 229 them. It is to be expected that this process will be slow. Until it 230 is complete, the new extension will fail in some parts of the 231 Internet. This aspect needs to be considered when deciding to 232 standardise a new extension. 234 4. IANA Considerations 236 IANA is requested to clearly mark in the Assigned Internet Protocol 237 Numbers registry those values which are also IPv6 Extension Header 238 types, for example by adding an extra column to indicate this. This 239 will also apply to any IPv6 Extension Header types defined in the 240 future. 242 Additionally, IANA is requested to replace the existing empty IPv6 243 Next Header Types registry by an IPv6 Extension Header Types 244 registry. It will contain only those protocol numbers which are also 245 marked as IPv6 Extension Header types in the Assigned Internet 246 Protocol Numbers registry. The initial list will be as follows: 247 o 0, Hop-by-Hop Options, [RFC2460] 248 o 43, Routing, [RFC2460], [RFC5095] 249 o 44, Fragment, [RFC2460] 250 o 50, Encapsulating Security Payload, [RFC4303] 251 o 51, Authentication, [RFC4302] 252 o 60, Destination Options, [RFC2460] 253 o 135, MIPv6, [RFC6275] 254 o 139, HIP, [RFC5201] 255 o 140, shim6, [RFC5533] 257 The references to the IPv6 Next Header field in [RFC2780] are to be 258 interpreted as also applying to the IPv6 Extension Header field. 260 5. Acknowledgements 262 This document was triggered by mailing list discussions including 263 John Leslie, Stefan Marksteiner and others. Valuable comments and 264 contributions were made by Dominique Barthel, Lorenzo Colitti, 265 Fernando Gont, Bob Hinden, Ray Hunter, Suresh Krishnan, Marc Lampo, 266 Michael Richardson, Dave Thaler, Joe Touch, and others. 268 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 269 University during part of this work. 271 This document was produced using the xml2rfc tool [RFC2629]. 273 6. Change log [RFC Editor: Please remove] 275 draft-carpenter-6man-ext-transmission-02: clarifications following WG 276 comments, recalibrated firewall requirements, 2013-02-22. 278 draft-carpenter-6man-ext-transmission-01: feedback at IETF85: clarify 279 scope and impact on firewalls, discuss line-speed processing and lack 280 of uniform TLV format, added references, restructured IANA 281 considerations, 2012-11-13. 283 draft-carpenter-6man-ext-transmission-00: original version, 284 2012-08-14. 286 7. References 288 7.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 294 (IPv6) Specification", RFC 2460, December 1998. 296 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 297 Values In the Internet Protocol and Related Headers", 298 BCP 37, RFC 2780, March 2000. 300 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 301 December 2005. 303 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 304 RFC 4303, December 2005. 306 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 307 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 309 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 310 of Type 0 Routing Headers in IPv6", RFC 5095, 311 December 2007. 313 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 314 "Host Identity Protocol", RFC 5201, April 2008. 316 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 317 Shim Protocol for IPv6", RFC 5533, June 2009. 319 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 320 in IPv6", RFC 6275, July 2011. 322 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 323 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 324 RFC 6564, April 2012. 326 7.2. Informative References 328 [Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. 330 [I-D.ietf-6man-oversized-header-chain] 331 Gont, F. and V. Manral, "Security and Interoperability 332 Implications of Oversized IPv6 Header Chains", 333 draft-ietf-6man-oversized-header-chain-02 (work in 334 progress), November 2012. 336 [I-D.taylor-v6ops-fragdrop] 337 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 338 M., and T. Taylor, "Why Operators Filter Fragments and 339 What It Implies", draft-taylor-v6ops-fragdrop-00 (work in 340 progress), October 2012. 342 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 343 June 1999. 345 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 346 Routing Header for Source Routes with the Routing Protocol 347 for Low-Power and Lossy Networks (RPL)", RFC 6554, 348 March 2012. 350 Authors' Addresses 352 Brian Carpenter 353 Department of Computer Science 354 University of Auckland 355 PB 92019 356 Auckland, 1142 357 New Zealand 359 Email: brian.e.carpenter@gmail.com 361 Sheng Jiang 362 Huawei Technologies Co., Ltd 363 Q14, Huawei Campus 364 No.156 Beiqing Road 365 Hai-Dian District, Beijing 100095 366 P.R. China 368 Email: jiangsheng@huawei.com