idnits 2.17.1 draft-carpenter-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 (November 13, 2012) is 4182 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. 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: May 17, 2013 November 13, 2012 8 Transmission of IPv6 Extension Headers 9 draft-carpenter-6man-ext-transmit-01 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 May 17, 2013. 37 Copyright Notice 39 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirement to Transmit Extension Headers . . . . . . . . . . . 4 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 6 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 An initial set of IPv6 extension headers was defined by [RFC2460], 68 which also described how they should be handled by intermediate 69 nodes, with the exception of the hop-by-hop options header: 71 "...extension headers are not examined or processed 72 by any node along a packet's delivery path, until the packet reaches 73 the node (or each of the set of nodes, in the case of multicast) 74 identified in the Destination Address field of the IPv6 header." 76 This provision allowed for the addition of new extension headers, 77 since it means that forwarding nodes should be completely transparent 78 to them. Thus, new extension headers could be introduced 79 progressively, used only by hosts that have been updated to create 80 and interpret them. Several such extension headers have been defined 81 since RFC 2460. 83 Unfortunately, experience has showed that the network is not 84 transparent to these headers. The main reason for this is that some 85 firewalls attempt to inspect the transport header or payload. This 86 means that they need to traverse the chain of extension headers, if 87 present, until they find the transport header (or an encrypted 88 payload). Unfortunately, because some IPv6 extension headers do not 89 follow a uniform TLV format, this process is clumsy and requires 90 knowledge of each extension header's format. 92 The process is slow as well as clumsy, precluding its use in nodes 93 attempting to process packets at line speed. The present document 94 does not intend to solve this problem, which is caused by the 95 fundamental architecture of IPv6 extension headers. This document 96 focuses on clarifying how the header chain should be traversed in the 97 current IPv6 architecture. 99 If they encounter an unknown extension header type, some firewalls 100 treat the packet as suspect and drop it. It is an established fact 101 that several widely used firewalls do not recognise some or all of 102 the extension headers defined since RFC 2460. It has also been 103 observed that certain firewalls do not even handle all the extension 104 headers in RFC 2460, including the fragment header 105 [I-D.taylor-v6ops-fragdrop], causing fundamental problems of 106 connectivity. This applies in particular to firewalls that attempt 107 to inspect packets statelessly at very high speed, since they cannot 108 take the time to reassemble fragmented packets, especially when under 109 a denial of service attack. 111 Other types of middlebox, such as load balancers or packet 112 classifiers, might also fail in the presence of extension headers 113 that they do not recognise. 115 A contributory factor to this problem is that, because extension 116 headers are numbered out of the existing IP Protocol Number space, 117 there is no collected list of them. For this reason, it is hard for 118 an implementor to quickly identify the full set of defined extension 119 headers. An implementor who consults only RFC 2460 will miss all 120 extension headers defined subsequently. 122 The uniform TLV format now defined for extension headers [RFC6564] 123 will improve the situation, but only for future extensions. Some 124 tricky cases would be avoided by forbidding very long chains of 125 extension headers that might otherwise be fragmented 126 [I-D.ietf-6man-oversized-header-chain]. 128 However, these changes are insufficient to correct the underlying 129 problem. The present document clarifies that the above requirement 130 from RFC 2460 applies to all types of node that forward IPv6 packets 131 and to all extension headers defined now and in the future. It also 132 requests IANA to create a subsidiary registry that clearly identifies 133 extension header types, and updates RFC 2780 accordingly. However, 134 fundamental changes to the IPv6 extension header architecture are out 135 of scope for this document. 137 Also, Hop-by-Hop options are not handled by many high speed routers, 138 or are processed only on a slow path. This document also updates the 139 requirements for processing the Hop-by-Hop options header to make 140 them more realistic. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 2. Requirement to Transmit Extension Headers 148 The IPv6 Hop-by-Hop Options header SHOULD be processed by 149 intermediate nodes as described in [RFC2460]. However, it is to be 150 expected that high performance routers will either ignore it, or 151 assign packets containing it to a slow processing path. Designers 152 planning to use a Hop-by-Hop option should be aware of this likely 153 behaviour. 155 As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options 156 header, if present, must be first. 158 Apart from that, any node along an IPv6 packet's path, which forwards 159 it for any reason, SHOULD do so regardless of any extension headers 160 that are present, as described in RFC 2460. Exceptionally, if this 161 node is designed to examine extension headers for any reason, such as 162 firewalling, it MUST recognise and deal appropriately with all IPv6 163 extension header types. The list of currently defined extension 164 header types is maintained by IANA (see Section 4). 166 RFC 2460 requires destination hosts to discard packets containing 167 unrecognised extension headers. However, intermediate forwarding 168 nodes MUST NOT do this by default, since that might cause them to 169 inadvertently discard traffic using a recently defined extension 170 header, not yet recognised by the intermediate node. 172 As mentioned above, firewalls that violate RFC 2460 by discarding 173 packets containing extension headers are known to cause connectivity 174 failures. Therefore, it is important that firewalls are capable of 175 parsing all defined IPv6 extension headers and behave according to 176 the above requirements. If a firewall chooses to discard a packet 177 containing a defined IPv6 extension header, it MUST be the result of 178 an explicitly configured firewall policy, and not just the result of 179 a failure to recognise such a header. To be clear, this means that 180 the default configuration of a firewall MUST NOT cause defined 181 extension headers to be discarded. Explicit configuration of a 182 discard policy is needed to change this. 184 The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD 185 NOT be used. However, as specified in [RFC5095], this does not mean 186 that the IPv6 Routing Header can be unconditionally dropped by 187 forwarding nodes. Packets containing undeprecated Routing Headers 188 MUST be forwarded by default. At the time of writing, these include 189 Type 2 [RFC6275], Type 3 [RFC6554], and Types 253 and 254 [RFC4727]. 190 Others may be defined in future. 192 3. Security Considerations 194 Firewall devices MUST conform to the requirements in the previous 195 section in order to respect the IPv6 extension header architecture. 196 In particular, packets containing specific extension headers are only 197 to be discarded as a result of explicit policy, and never as a result 198 of the default configuration. 200 When new extension headers are defined in the future, those 201 implementing and configuring firewalls will need to take account of 202 them. It is to be expected that this process will be slow. Until it 203 is complete, the new extension will fail in some parts of the 204 Internet. This aspect needs to be considered when deciding to 205 standardise a new extension. 207 4. IANA Considerations 209 IANA is requested to clearly mark in the Assigned Internet Protocol 210 Numbers registry those values which are also IPv6 Extension Header 211 types, for example by adding an extra column to indicate this. This 212 will also apply to any IPv6 Extension Header types defined in the 213 future. 215 Additionally, IANA is requested to replace the existing empty IPv6 216 Next Header Types registry by an IPv6 Extension Header Types 217 registry. It will contain only those protocol numbers which are also 218 marked as IPv6 Extension Header types in the Assigned Internet 219 Protocol Numbers registry. The initial list will be as follows: 220 o 0, Hop-by-Hop Options, [RFC2460] 221 o 43, Routing, [RFC2460], [RFC5095] 222 o 44, Fragment, [RFC2460] 223 o 50, Encapsulating Security Payload, [RFC4303] 224 o 51, Authentication, [RFC4302] 225 o 58, ICMPv6, [RFC2460] 226 o 59, No Next Header, [RFC2460] 227 o 60, Destination Options, [RFC2460] 228 o 135, MIPv6, [RFC6275] 229 o 139, HIP, [RFC5201] 230 o 140, shim6, [RFC5533] 232 The references to the IPv6 Next Header field in [RFC2780] are to be 233 interpreted as also applying to the IPv6 Extension Header field. 235 5. Acknowledgements 237 This document was triggered by mailing list discussions including 238 John Leslie, Stefan Marksteiner and others. Valuable comments and 239 contributions were made by Dominique Barthel, Lorenzo Colitti, 240 Fernando Gont, Suresh Krishnan, Michael Richardson, Dave Thaler, Joe 241 Touch, and others. 243 Brian Carpenter was a visitor at the Computer Laboratory, Cambridge 244 University during part of this work. 246 This document was produced using the xml2rfc tool [RFC2629]. 248 6. Change log [RFC Editor: Please remove] 250 draft-carpenter-6man-ext-transmission-01: feedback at IETF85: clarify 251 scope and impact on firewalls, discuss line-speed processing and lack 252 of uniform TLV format, added references, restructured IANA 253 considerations, 2012-11-13. 255 draft-carpenter-6man-ext-transmission-00: original version, 256 2012-08-14. 258 7. References 260 7.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 266 (IPv6) Specification", RFC 2460, December 1998. 268 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 269 Values In the Internet Protocol and Related Headers", 270 BCP 37, RFC 2780, March 2000. 272 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 273 December 2005. 275 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 276 RFC 4303, December 2005. 278 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 279 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 281 [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation 282 of Type 0 Routing Headers in IPv6", RFC 5095, 283 December 2007. 285 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 286 "Host Identity Protocol", RFC 5201, April 2008. 288 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 289 Shim Protocol for IPv6", RFC 5533, June 2009. 291 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 292 in IPv6", RFC 6275, July 2011. 294 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 295 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 296 RFC 6564, April 2012. 298 7.2. Informative References 300 [I-D.ietf-6man-oversized-header-chain] 301 Gont, F. and V. Manral, "Security and Interoperability 302 Implications of Oversized IPv6 Header Chains", 303 draft-ietf-6man-oversized-header-chain-02 (work in 304 progress), November 2012. 306 [I-D.taylor-v6ops-fragdrop] 307 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 308 M., and T. Taylor, "Why Operators Filter Fragments and 309 What It Implies", draft-taylor-v6ops-fragdrop-00 (work in 310 progress), October 2012. 312 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 313 June 1999. 315 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 316 Routing Header for Source Routes with the Routing Protocol 317 for Low-Power and Lossy Networks (RPL)", RFC 6554, 318 March 2012. 320 Authors' Addresses 322 Brian Carpenter 323 Department of Computer Science 324 University of Auckland 325 PB 92019 326 Auckland, 1142 327 New Zealand 329 Email: brian.e.carpenter@gmail.com 331 Sheng Jiang 332 Huawei Technologies Co., Ltd 333 Q14, Huawei Campus 334 No.156 Beiqing Road 335 Hai-Dian District, Beijing 100095 336 P.R. China 338 Email: jiangsheng@huawei.com