idnits 2.17.1 draft-gont-6man-rfc6564bis-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 : ---------------------------------------------------------------------------- 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 (September 16, 2015) is 3143 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 246, but not defined == Unused Reference: 'RFC2460' is defined on line 259, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-gont-v6ops-ipv6-ehs-packet-drops-00 Summary: 1 error (**), 0 flaws (~~), 4 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: March 19, 2016 S. Krishnan 7 Ericsson 8 H. Pfeifer 9 Rohde & Schwarz 10 September 16, 2015 12 IPv6 Universal Extension Header 13 draft-gont-6man-rfc6564bis-01 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 March 19, 2016. 43 Copyright Notice 45 Copyright (c) 2015 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. Forbidding New IPv6 Extension Headers . . . . . . . . . . . . 5 66 7. Operation of the UEH . . . . . . . . . . . . . . . . . . . . 5 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 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 packets employing Extension Headers are dropped in the public 81 Internet [GONT-IEPG-Nov13] [GONT-IEPG-Mar14], and debate about the 82 motivation behind such policy [I-D.gont-v6ops-ipv6-ehs-packet-drops]. 83 Secondly, there has been a fair share of work to improve some 84 technicalities of IPv6 Extension Headers (see e.g. [RFC7112] 85 [RFC7045]) in the hopes that they can be reliably used in the public 86 Internet. 88 A key challenge for IPv6 Extension Headers to be "deployable" in the 89 public Internet is that they should not impair any nodes's ability to 90 process the entire IPv6 header chain. One of the steps meant in that 91 direction has been the specification of a Uniform Format for IPv6 92 Extension Headers [RFC6564], which was meant to be employed by any 93 IPv6 Extension Headers that might be defined in the future, such that 94 middle-boxes can still process the entire IPv6 header chain if new 95 new extension headers were specified. However, a problem in the 96 aforementioned specification prevents such uniform format from being 97 of use. 99 Section 3 discusses the aforementioned flaw in the Uniform Format for 100 Extension Headers specified in [RFC6564]. Section 4 explicitly 101 describes the implications of the aforementioned flaw. Section 5 102 specifies the new Universal Extension Header (UEH). Section 7 103 explains how new IPv6 extensions would be specified with the UEH. 104 Section 6 formally forbids the specification of new IPv6 Extension 105 Headers (with new Next Header values), and mandates that any new IPv6 106 extensions be conveyed/encoded in the UEH specified in 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 "Next Header" registry/namespace. Thus, 119 given an "unknown Next Header value", it is impossible to tell 120 whether the aforementioned value refers to an IPv6 Extension Header 121 that employs the aforementioned uniform format, or an "unknown" 122 upper-layer protocol (e.g. an "unknown" transport protocol). That 123 is, while [RFC6564] specifies the syntax for a Uniform Format for 124 IPv6 Extension Headers, it does not provide a mechanism for a node to 125 identify whether the aforementioned format is being employed in the 126 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 new 133 transport protocols. Namely, 135 o New IPv6 extension headers cannot be incrementally deployed. 137 o New transport protocols cannot be incrementally 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 145 [I-D.gont-v6ops-ipv6-ehs-packet-drops]. In a similar way, a 146 middlebox that needs to process the transport-protocol header will be 147 faced with the dilemma of what to do with packets that employ unknown 148 Next Header values. Since they will not be able to parse the IPv6 149 header chain past the unknown Next Header, it is very likely that 150 they will drop such packets. 152 Unfortunately, since transport protocols share the same namespace as 153 IPv6 Extension Headers, new transport protocols will pose the same 154 challenge to middle-boxes, and hence they will be likely dropped in 155 the network. 157 We believe that the current situation has implications that are 158 generally overlooked, and that, whatever the outcome, it should be 159 the result of an explicit decision by our community, rather than 160 simply "omission". 162 5. UEH Specification 164 This document specifies a new IPv6 Extension Header: Universal 165 Extension Header. This Extension Header is identified by the value 166 [TBD] of [IANA-IP-PROTO]. The syntax of the Universal Extension 167 Header is: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Next Header | Hdr Ext Len | Subtype | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 174 | | 175 . . 176 . Subtype Specific Data . 177 . . 178 | | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 where: 183 Next Header 184 8-bit selector. Identifies the type of header immediately 185 following the extension header. Uses the same values as the IPv4 186 Protocol field [IANA-IP-PROTO]. 188 Hdr Ext Len 189 8-bit unsigned integer. Length of the extension header in 8-octet 190 units, not including the first 8 octets. 192 Subtype 193 8-bit unsigned integer. Specifies the subtype for this extension 194 header. It uses a new namespace managed by IANA [IANA-UEH]. 196 Subtype Specific Data 197 Variable length. Fields specific to this extension header/ 198 Subtype. 200 The Universal Extension Header specified in this document MAY appear 201 multiple times in the same IPv6 packet. 203 6. Forbidding New IPv6 Extension Headers 205 Since the specification of any new IPv6 Extension Headers (i.e., with 206 new Next Header values) would hamper (among other things) the 207 incremental deployment of extensions and new transport protocols, and 208 basic operational practices such as the enforcement of simple ACLs, 209 new IPv6 Extension Headers MUST NOT be specified in any future 210 specifications. Any IPv6 extensions that would require a new IPv6 211 Extension Header MUST be implemented with the Universal Extension 212 Header specified in this document. This minimizes breakage in 213 intermediate nodes that need to parse the entire IPv6 header chain. 215 7. Operation of the UEH 217 This section describes the operation of the Universal Extension 218 Header. 220 The goal of the UEH is to provide a common syntax for all future IPv6 221 extensions. Any future extension headers will be encoded in a UEH, 222 and will be identified by a specific UEH Subtype assigned by IANA at 223 the time the corresponding specification is published. The UEH thus 224 provides the "common syntax" required to process "unrecognized 225 extensions", and the Subtype field identifies the specific extension 226 being encoded in the UEH. Any "future extension headers" would 227 actually be new Subtypes (assigned by IANA) of the UEH. 229 As a result, unrecognized Next Header values should be interpreted to 230 identify an upper-layer protocol, rather than an IPv6 extension 231 header. 233 8. IANA Considerations 235 IANA is requested to create a new registry to maintain the Universal 236 Extension Header Subtypes [IANA-UEH]. 238 9. Security Considerations 240 Enabling nodes to parse an entire IPv6 header chain even in the 241 presence of unrecognized extensions allows for security mechanisms to 242 be implemented and deployed. 244 10. Acknowledgements 246 The authors would like to thank [TBD] for providing valuable input on 247 earlier versions of this document. 249 11. Contributors 251 C.M. Heard identified the problems related with the Uniform Format 252 for IPv6 Extension Headers specified in [RFC6564], and participated 253 in the brainstorming that led to this document. 255 12. References 257 12.1. Normative References 259 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 260 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 261 December 1998, . 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 269 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 270 RFC 6564, DOI 10.17487/RFC6564, April 2012, 271 . 273 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 274 of IPv6 Extension Headers", RFC 7045, 275 DOI 10.17487/RFC7045, December 2013, 276 . 278 12.2. Informative References 280 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 281 Oversized IPv6 Header Chains", RFC 7112, 282 DOI 10.17487/RFC7112, January 2014, 283 . 285 [I-D.gont-v6ops-ipv6-ehs-packet-drops] 286 Gont, F., Hilliard, N., Doering, G., LIU, S., and W. 287 Kumari, "Operational Implications of IPv6 Packets with 288 Extension Headers", draft-gont-v6ops-ipv6-ehs-packet- 289 drops-00 (work in progress), July 2015. 291 [GONT-IEPG-Nov13] 292 Gont, F., "Fragmentation and Extension Header Support in 293 the IPv6 Internet", IEPG 88, November 3, 2013. Vancouver, 294 BC, Canada, 2013, . 297 [GONT-IEPG-Mar14] 298 Gont, F. and T. Chown, "More results from measurements of 299 IPv6 Extension Header probing", IEPG 89, March 2, 2014. 300 London, U.K., 2014, . 303 [IANA-IP-PROTO] 304 Internet Assigned Numbers Authority, "Assigned Internet 305 Protocol Numbers", April 2011, 306 . 309 [IANA-UEH] 310 Internet Assigned Numbers Authority, "Universal Extension 311 Header Subtypes", 2014. 313 Authors' Addresses 315 Fernando Gont 316 SI6 Networks / UTN-FRH 317 Evaristo Carriego 2644 318 Haedo, Provincia de Buenos Aires 1706 319 Argentina 321 Phone: +54 11 4650 8472 322 Email: fgont@si6networks.com 323 URI: http://www.si6networks.com 325 Will (Shucheng) Liu 326 Huawei Technologies 327 Bantian, Longgang District 328 Shenzhen 518129 329 P.R. China 331 Email: liushucheng@huawei.com 332 Suresh Krishnan 333 Ericsson 334 8400 Decarie Blvd. 335 Town of Mount Royal, QC 336 Canada 338 Phone: +1 514 345 7900 x42871 339 Email: suresh.krishnan@ericsson.com 341 Hagen Paul Pfeifer 342 Rohde & Schwarz 343 Muehldorfstrasse 15 344 Munich 81671 345 Germany 347 Phone: +49 89 4129 15515 348 Email: hagen.pfeifer@rohde-schwarz.com 349 URI: http://www.rohde-schwarz.com/