idnits 2.17.1 draft-ietf-6man-exthdr-06.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 RFC2460, but the abstract doesn't seem to mention this, which it should. 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 (January 12, 2012) is 4487 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Updates: 2460 (if approved) j h. woodyatt 5 Intended status: Standards Track Apple 6 Expires: July 15, 2012 E. Kline 7 Google 8 J. Hoagland 9 Symantec 10 M. Bhatia 11 Alcatel-Lucent 12 January 12, 2012 14 An uniform format for IPv6 extension headers 15 draft-ietf-6man-exthdr-06 17 Abstract 19 In IPv6, optional internet-layer information is encoded in separate 20 headers that may be placed between the IPv6 header and the transport 21 layer header. There are a small number of such extension headers 22 currently defined. This document describes the issues that can arise 23 when defining new extension headers and discusses the alternate 24 extension mechanisms in IPv6. It also provides a common format for 25 defining any new IPv6 extension headers if they are needed. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 15, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions used in this document . . . . . . . . . . . . . . . 3 63 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Proposed IPv6 Extension Header format . . . . . . . . . . . . . 5 65 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 66 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 10. Normative References . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 The base IPv6 standard [RFC2460] defines extension headers as an 76 expansion mechanism to carry optional internet layer information. 77 Extension headers, with the exception of the hop-by-hop options 78 header, are not usually processed on intermediate nodes. However, 79 Several existing deployed IPv6 routers and several existing deployed 80 IPv6 firewalls, in contradiction to [RFC2460], are capable of parsing 81 past or ignoring all currently defined IPv6 Extension Headers (e.g. 82 to examine transport-layer header fields) at wire-speed (e.g. by 83 using custom ASICs for packet processing). Hence, one must also 84 consider that any new IPv6 Extension Header will break IPv6 85 deployments that use these existing capabilities. 87 Any IPv6 header or option that has hop-by-hop behaviour, and is 88 intended for general use in the public IPv6 Internet, could be 89 subverted to create an attack on IPv6 routers processing packets 90 containing such a header or option. Reports from the field indicate 91 that some IP routers deployed within the global Internet are 92 configured either to ignore the presence of headers with hop-by-hop 93 behaviour or to drop packets containing headers with hop-by-hop 94 behaviour. 96 2. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Applicability 104 The base IPv6 standard [RFC2460] allows the use of both extension 105 headers and destination options in order to encode optional 106 destination information in an IPv6 packet. The use of destination 107 options to encode this information, provides more flexible handling 108 characteristics and better backward compatibility than using 109 extension headers. Because of this, implementations SHOULD use 110 destination options as the preferred mechanism for encoding optional 111 destination information, and use a new extension header only if 112 destination options do not satisfy their needs. The request for 113 creation of a new IPv6 extension header MUST be accompanied by an 114 specific explanation of why destination options could not be used to 115 convey this information. 117 The base IPv6 standard [RFC2460] defines 3 extension headers (i.e. 118 Routing Header, Destination Options Header, Hop-by-Hop Options 119 Header) to be used for any new IPv6 options. The same standard only 120 allows the creation of new Extension Headers in limited circumstances 121 [RFC2460] Section 4.6. 123 As noted above, the use of any option with Hop-by-Hop behaviour can 124 be problematic in the global public Internet. New IPv6 Extension 125 Header(s) having hop-by-hop behaviour MUST NOT be created or 126 specified. New options for the existing Hop-by-Hop Header SHOULD NOT 127 be created or specified unless no alternative solution is feasible. 128 Any proposal to create a new option for the existing Hop-by-Hop 129 Header MUST include a detailed explanation of why the hop-by-hop 130 behaviour is absolutely essential in the Internet-Draft proposing the 131 new option with hop-by-hop behaviour. 133 The use of IPv6 Destination Options to encode information provides 134 more flexible handling characteristics and better backward 135 compatibility than using a new Extension Header. Because of this, 136 new optional information to be sent SHOULD be encoded in a new option 137 for the existing IPv6 Destination Options Header. 139 Mindful of the need for compatibility with existing IPv6 deployments, 140 new IPv6 extension headers MUST NOT be created or specified, unless 141 no existing IPv6 Extension Header can be used by specifying a new 142 option for that existing IPv6 Extension Header. Any proposal to 143 create or specify a new IPv6 Extension Header MUST include a detailed 144 technical explanation of why no existing IPv6 Extension Header can be 145 used in the Internet-Draft proposing the new IPv6 Extension Header. 147 4. Proposed IPv6 Extension Header format 149 Any IPv6 Extension Headers are defined in future, keeping in mind the 150 restrictions specified in Section 3 and also the restrictions 151 specified in [RFC2460], MUST use the consistent format defined in 152 Figure 1. This minimizes breakage in intermediate nodes that examine 153 these extension headers. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Next Header | Hdr Ext Len | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 160 | | 161 . . 162 . Header Specific Data . 163 . . 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Next Header 8-bit selector. Identifies the type of header 168 immediately following the Extension header. 169 Uses the same values as the IPv4 Protocol 170 field [IANA_IP_PARAM]. 171 Hdr Ext Len 8-bit unsigned integer. Length of the 172 Extension header in 8-octet units, not 173 including the first 8 octets. 174 Header Specific Variable length. Fields specific to the 175 Data extension header 177 Figure 1: Extension header layout 179 5. Backward Compatibility 181 The scheme proposed in this document is not intended to be backward 182 compatible with all the currently defined IPv6 extension headers. It 183 applies only to newly defined extension headers. Specifically, the 184 fragment header predates this document and does not follow the format 185 proposed in this document. 187 6. Future work 189 This document proposes one step in easing the inspection of extension 190 headers by middleboxes. There is further work required in this area. 191 Some issues that are left unresolved beyond this document include 192 o There can be an arbitrary number of extension headers. 193 o Extension headers must be processed in the order they appear. 194 o Extension headers may alter the processing of the payload itself, 195 and hence the packet may not be processed properly without 196 knowledge of said header. 198 7. IANA Considerations 200 This document does not require any IANA actions. 202 8. Security Considerations 204 This document proposes a standard format for the IPv6 extension 205 headers that minimizes breakage at intermediate nodes that inspect 206 but do not understand the contents of these headers. Intermediate 207 nodes, such as firewalls, that skip over unknown headers might end up 208 allowing the setup of a covert channel from the outside of the 209 firewall to the inside using the data field(s) of the unknown 210 extension headers. 212 9. Acknowledgements 214 The authors would like to thank Albert Manfredi, Bob Hinden, Brian 215 Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela, 216 Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel 217 Halpern, Ran Atkinson, Steven Blake, Jari Arkko, Kathleen Moriarty, 218 Stephen Farrell, Ralph Droms, Sean Turner and Adrian Farrell for 219 their reviews and suggestions that made this document better. 221 10. Normative References 223 [IANA_IP_PARAM] 224 IANA, "IP Parameters", 225 . 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 231 (IPv6) Specification", RFC 2460, December 1998. 233 Authors' Addresses 235 Suresh Krishnan 236 Ericsson 237 8400 Decarie Blvd. 238 Town of Mount Royal, QC 239 Canada 241 Phone: +1 514 345 7900 x42871 242 Email: suresh.krishnan@ericsson.com 244 james woodyatt 245 Apple Inc. 246 1 Infinite Loop 247 Cupertino, CA 95014 248 US 250 Email: jhw@apple.com 252 Erik Kline 253 Google 254 Mori Tower 26F 255 Roppongi 6-10-1 256 Minato ku 257 Tokyo 106-6126 258 Japan 260 Phone: +81 3-6384-9635 261 Email: ek@google.com 263 James Hoagland 264 Symantec Corporation 265 350 Ellis St. 266 Mountain View, CA 94043 267 US 269 Email: Jim_Hoagland@symantec.com 270 URI: http://symantec.com/ 271 Manav Bhatia 272 Alcatel-Lucent 273 Bangalore 274 India 276 Email: manav.bhatia@alcatel-lucent.com