idnits 2.17.1 draft-gont-6man-rfc6564bis-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2014) is 3661 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) == Missing Reference: 'TBD' is mentioned on line 251, but not defined == Unused Reference: 'RFC2460' is defined on line 264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Obsoletes: 6564 (if approved) W. Liu 5 Intended status: Standards Track Huawei Technologies 6 Expires: October 10, 2014 S. Krishnan 7 Ericsson 8 H. Pfeifer 9 Rohde & Schwarz 10 April 8, 2014 12 IPv6 Universal Extension Header 13 draft-gont-6man-rfc6564bis-00 15 Abstract 17 In IPv6, optional internet-layer information is encoded in separate 18 headers that may be placed between the IPv6 header and the transport- 19 layer header. There are a small number of such extension headers 20 currently defined. This document describes the issues that can arise 21 when defining new extension headers and specifies a new IPv6 22 Extension Header - the Universal Extension Header - that overcomes 23 the aforementioned problem, while enabling the extensibility of IPv6. 24 Finally, this document formally obsoletes RFC 6564. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 10, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. A Problem with RFC 6564 . . . . . . . . . . . . . . . . . . . 3 63 4. Implications . . . . . . . . . . . . . . . . . . . . . . . . 3 64 5. UEH Specification . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Operation of the UEH . . . . . . . . . . . . . . . . . . . . 5 66 7. Forbidding New IPv6 Extension Headers . . . . . . . . . . . . 5 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 12.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 There has recently been a lot of work in the area of IPv6 Extension 79 Headers. Firstly, there has been research about the extent to which 80 IPv6 Extension Headers are dropped in the public Internet 81 [GONT-IEPG-Nov13] [GONT-IEPG-Mar14], and debate about the motivation 82 behind such policy [I-D.taylor-v6ops-fragdrop]. Secondly, there has 83 been a fair share of work to improve some technicalities of IPv6 84 Extension Headers [RFC7112] [RFC7045], in the hopes that they can be 85 reliably used in the public Internet. 87 A key challenge for IPv6 Extension Headers to be "deployable" in the 88 public Internet is that they should not impair any nodes's ability to 89 process the entire IPv6 header chain. One of the steps meant in that 90 direction has been the specification of a Uniform Format for IPv6 91 Extension Headers [RFC6564], which was meant to be employed by any 92 IPv6 Extension Headers that might be defined in the future, such that 93 middle-boxes can still process the entire IPv6 header chain if the 94 new extension headers employ the Uniform Format. However, a problem 95 in the aforementioned specification prevents such uniform format from 96 being of use in practice. 98 Section 3 discusses the aforementioned flaw in the Uniform Format for 99 Extension Headers specified in [RFC6564]. Section 4 explicitly 100 describes the implications of the aforementioned flaw. Section 5 101 formally updates [RFC6564], specifying the new Universal Extension 102 Header (UEH). Section 6 explains how new IPv6 would be developed 103 with the UEH. Section 7 formally forbids the specification of new 104 IPv6 Extension Headers (with new Next Header values), and mandates 105 that any new IPv6 Extensions be encoded with the UEH specified in 106 this document. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. A Problem with RFC 6564 116 A key problem with the Uniform Format for IPv6 Extension Headers 117 [RFC6564] lies in that both IPv6 Extension Headers and Transport 118 Protocols share the same namespace ("Next Header" registry/ 119 namespace). Thus, given an "unknown Next Header value", it is 120 impossible to tell whether the aforementioned value refers to an IPv6 121 Extension Header that employs the aforementioned uniform format, or 122 an "unknown" upper-layer protocol (e.g. an "unknown" transport 123 protocol). That is, while [RFC6564] specifies the syntax for the 124 Uniform Format for IPv6 Extension Headers, but it does not provide a 125 mechanism for a node to identify whether the aforementioned format is 126 being employed in the first place. 128 4. Implications 130 The current impossibility to parse an IPv6 header chain that includes 131 unknown Next Header values results in concrete implications for the 132 extensibility of the IPv6 protocol, and the deployability of IPv6 133 extension headers. Namely, 135 o New IPv6 extension headers cannot be incrementally deployed. 137 o New transport protocols cannot be deployed. 139 Since there is no way for a node to process IPv6 extension headers 140 that employ unknown next header values, an IPv6 host that receives a 141 packet that employs a new IPv6 extension header will not be able to 142 parse the IPv6 header chain past that unknown extension header, and 143 hence it will drop the aforementioned packet. In a similar way, a 144 middlebox that needs to process the transport-protocol header will be 145 faced with the dilemma of what to do with packets that employ unknown 146 Next Header values. Since they will not be able to parse the IPv6 147 header chain past the unknown Next Header, it is very likely that 148 they will drop such packets. 150 Unfortunately, since transport protocols share the same namespace as 151 IPv6 Extension Headers, new transport protocols will pose the same 152 challenge to middle-boxes, and hence they will be likely dropped in 153 the network. 155 We believe that the current situation has implications that are 156 generally overlooked, and that, whatever the outcome, it should be 157 the result of an explicit decision by our community, rather than 158 simply "omission". 160 5. UEH Specification 162 The entire Section 4 of [RFC6564] is hereby replaced as follows: 164 New IPv6 Extension Headers MUST NOT be specified. Any IPv6 165 extensions that would require a new IPv6 Extension Header MUST be 166 implemented with the Universal Extension Header specified in this 167 document. This minimizes breakage in intermediate nodes that examine 168 these extension headers. 170 This document specifies a new IPv6 Extension Header: Universal 171 Extension Header. This Extension Header is identified by the value 172 [TBD] of [IANA-IP-PROTO]. The syntax of the Universal Extension 173 Header is: 175 0 1 2 3 176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Next Header | Hdr Ext Len | Subtype | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 180 | | 181 . . 182 . Subtype Specific Data . 183 . . 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 where: 189 Next Header 190 8-bit selector. Identifies the type of header immediately 191 following the extension header. Uses the same values as the IPv4 192 Protocol field [IANA-IP-PROTO]. 194 Hdr Ext Len 195 8-bit unsigned integer. Length of the extension header in 8-octet 196 units, not including the first 8 octets. 198 Subtype 199 8-bit unsigned integer. Specifies the subtype for this extension 200 header. It uses a new namespace managed by IANA [IANA-UEH]. 202 Subtype Specific Data 203 Variable length. Fields specific to this extension header/ 204 Subtype. 206 The Universal Extension Header specified in this document MAY appear 207 multiple times in the same IPv6 packet. 209 6. Operation of the UEH 211 This section discusses de operation of the Universal Extension 212 Header. 214 The goal of the UEH is to provide for a common syntax for all future 215 IPv6 extensions. Any future extension headers will be encoded in a 216 UEH, and will be identified by a specific UEH Subtype assigned by 217 IANA at the time the corresponding specification is published. The 218 UEH thus provides for the "common syntax" required to process 219 "unrecognized extensions", and the Subtype field identifies the 220 specific extension being encoded in the UEH. Any "future extension 221 headers" would actually be new Subtypes (assigned by IANA) of the 222 UEH. 224 As a result, in the event an unrecognized Next Header value is 225 encountered by a node, the node will be able to assume that such Next 226 Header value identifies an upper-layer protocol, rather than an 227 extension header. 229 7. Forbidding New IPv6 Extension Headers 231 Since the specification of any new IPv6 Extension Headers (i.e., with 232 new Next Header values) would hamper (among other things) the 233 incremental deployment of extensions and enforcement of simple ACLs, 234 new IPv6 Extension Headers MUST NOT be specified in any future 235 specifications. Any new IPv6 extensions MUST be specified by means 236 of the UEH specified in this document. 238 8. IANA Considerations 240 IANA is requested to create a new registry to maintain the Universal 241 Extension Header Subtypes [IANA-UEH]. 243 9. Security Considerations 245 Enabling nodes to parse an entire IPv6 header chain even in the 246 presence of unrecognized extensions allows for security mechanisms to 247 be implemented and deployed. 249 10. Acknowledgements 251 The authors would like to thank [TBD] for providing valuable input on 252 earlier versions of this document. 254 11. Contributors 256 C.M. Heard identified the problems related with the Uniform Format 257 for IPv6 Extension Headers specified in [RFC6564], and participated 258 in the brainstorming that led to this document. 260 12. References 262 12.1. Normative References 264 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 265 (IPv6) Specification", RFC 2460, December 1998. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 271 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 272 RFC 6564, April 2012. 274 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 275 of IPv6 Extension Headers", RFC 7045, December 2013. 277 12.2. Informative References 279 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 280 Oversized IPv6 Header Chains", RFC 7112, January 2014. 282 [I-D.taylor-v6ops-fragdrop] 283 Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, 284 M., and T. Taylor, "Why Operators Filter Fragments and 285 What It Implies", draft-taylor-v6ops-fragdrop-02 (work in 286 progress), December 2013. 288 [GONT-IEPG-Nov13] 289 Gont, F., "Fragmentation and Extension Header Support in 290 the IPv6 Internet", IEPG 88, November 3, 2013. Vancouver, 291 BC, Canada, 2013, . 294 [GONT-IEPG-Mar14] 295 Gont, F. and T. Chown, "More results from measurements of 296 IPv6 Extension Header probing", IEPG 89, March 2, 2014. 297 London, U.K., 2014, . 300 [IANA-IP-PROTO] 301 Internet Assigned Numbers Authority, "Assigned Internet 302 Protocol Numbers", April 2011, . 305 [IANA-UEH] 306 Internet Assigned Numbers Authority, "Universal Extension 307 Header Subtypes", 2014. 309 Authors' Addresses 311 Fernando Gont 312 SI6 Networks / UTN-FRH 313 Evaristo Carriego 2644 314 Haedo, Provincia de Buenos Aires 1706 315 Argentina 317 Phone: +54 11 4650 8472 318 Email: fgont@si6networks.com 319 URI: http://www.si6networks.com 321 Will (Shucheng) Liu 322 Huawei Technologies 323 Bantian, Longgang District 324 Shenzhen 518129 325 P.R. China 327 Email: liushucheng@huawei.com 328 Suresh Krishnan 329 Ericsson 330 8400 Decarie Blvd. 331 Town of Mount Royal, QC 332 Canada 334 Phone: +1 514 345 7900 x42871 335 Email: suresh.krishnan@ericsson.com 337 Hagen Paul Pfeifer 338 Rohde & Schwarz 339 Muehldorfstrasse 15 340 Munich 81671 341 Germany 343 Phone: +49 89 4129 15515 344 Email: hagen.pfeifer@rohde-schwarz.com 345 URI: http://www.rohde-schwarz.com/