idnits 2.17.1 draft-ietf-6man-exthdr-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 11, 2011) is 4665 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 (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Standards Track j h. woodyatt 5 Expires: January 12, 2012 Apple 6 E. Kline 7 Google 8 J. Hoagland 9 Symantec 10 M. Bhatia 11 Alcatel-Lucent 12 July 11, 2011 14 An uniform format for IPv6 extension headers 15 draft-ietf-6man-exthdr-04 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 alternative 24 extension mechanisms in IPv6. It also provides a format for defining 25 new IPv6 extension headers that would allow implementations to 26 process past unknown extension headers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 12, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . . 3 64 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Proposed IPv6 Extension Header format . . . . . . . . . . . . . 5 66 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5 67 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 71 10. Normative References . . . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The base IPv6 standard [RFC2460] defines extension headers as an 77 expansion mechanism to carry optional internet layer information. 78 Extension headers, with the exception of the hop-by-hop options 79 header, are not usually processed on intermediate nodes. However, 80 some intermediate nodes such as firewalls, may need to look at the 81 transport layer header fields in order to make a decision to allow or 82 deny the packet. If new extension headers are defined and the 83 intermediate node is not aware of them, the intermediate node cannot 84 proceed further in the header chain since it does not know where the 85 unknown header ends and the next header begins. The main issue is 86 that the extension header format is not standardized and hence it is 87 not possible to skip past the unknown header. This document intends 88 to define a standard format for IPv6 extension headers. 90 Also, Several existing deployed IPv6 routers and several existing 91 deployed IPv6 firewalls are capable of parsing past or ignoring all 92 currently defined IPv6 Extension Headers (e.g. to examine transport- 93 layer header fields) at wire-speed (e.g. by using custom ASICs for 94 packet processing). Hence, one must also consider that any new IPv6 95 Extension Header will break IPv6 deployments that use these existing 96 capabilities. 98 Any IPv6 header or option that has hop-by-hop behaviour and is 99 intended for general use in the public IPv6 Internet could be 100 subverted to create an attack on IPv6 routers processing packets 101 containing such a header or option. Reports from the field indicate 102 that some IP routers deployed within the global Internet are 103 configured either to ignore the presence of headers with hop-by-hop 104 behaviour or to drop packets containing headers with hop-by-hop 105 behaviour. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Applicability 115 The base IPv6 standard [RFC2460] allows the use of both extension 116 headers and destination options in order to encode optional 117 destination information in an IPv6 packet. The use of destination 118 options to encode this information, provides more flexible handling 119 characteristics and better backward compatibility than using 120 extension headers. Because of this, implementations SHOULD use 121 destination options as the preferred mechanism for encoding optional 122 destination information, and use a new extension header only if 123 destination options do not satisfy their needs. The request for 124 creation of a new IPv6 extension header MUST be accompanied by an 125 specific explanation of why destination options could not be used to 126 convey this information. 128 The base IPv6 standard [RFC2460] defines 3 extension headers (i.e. 129 Routing Header, Destination Options Header, Hop-by-Hop Options 130 Header) to be used for any new IPv6 options. The same standard only 131 allows the creation of new Extension Headers in limited circumstances 132 [RFC2460] Section 4.6. 134 As noted above, the use of any option with Hop-by-Hop behaviour can 135 be problematic in the global public Internet. So new IPv6 Extension 136 Header(s) having hop-by-hop behaviour MUST NOT be created or 137 specified. Also, new options for the existing Hop-by-Hop Header 138 SHOULD NOT be created or specified unless no alternative is feasible. 139 Any proposal to create a new option for the existing Hop-by-Hop 140 Header MUST include a detailed explanation of why the hop-by-hop 141 behaviour is absolutely essential in the Internet-Draft proposing the 142 new option with hop-by-hop behaviour. 144 The use of IPv6 Destination Options to encode information provides 145 more flexible handling characteristics and better backward 146 compatibility than using a new Extension Header. Because of this, 147 new optional information to be sent SHOULD be encoded in a new option 148 for the existing IPv6 Destination Options Header. 150 Mindful of the need for compatibility with existing IPv6 deployments, 151 new IPv6 extension headers MUST NOT be created or specified, unless 152 no existing IPv6 Extension Header can be used by specifying a new 153 option for that existing IPv6 Extension Header. Any proposal to 154 create or specify a new IPv6 Extension Header MUST include a detailed 155 technical explanation of why no existing IPv6 Extension Header can be 156 used in the Internet-Draft proposing the new IPv6 Extension Header. 158 4. Proposed IPv6 Extension Header format 160 If any IPv6 Extension Headers are defined in future, keeping in mind 161 the restrictions specified in Section 3 and also the restrictions 162 specified in [RFC2460], they MUST use the consistent format defined 163 in Figure 1. This enables future IPv6 implementations to skip over 164 unknown IPv6 Extension Headers and continue to further process the 165 IPv6 header chain. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Next Header | Hdr Ext Len | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 172 | | 173 . . 174 . Header Specific Data . 175 . . 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Next Header 8-bit selector. Identifies the type of header 180 immediately following the Extension header. 181 Uses the same values as the IPv4 Protocol 182 field. 183 Hdr Ext Len 8-bit unsigned integer. Length of the 184 Extension header in 8-octet units, not 185 including the first 8 octets. 186 Header Specific Variable length. Fields specific to the 187 Data extension header 189 Figure 1: Extension header layout 191 5. Backward Compatibility 193 The scheme proposed in this document is not intended to be backward 194 compatible with all the currently defined IPv6 extension headers. It 195 applies only to newly defined extension headers. Specifically, the 196 fragment header predates this document and does not follow the format 197 proposed in this document. 199 6. Future work 201 This document proposes one step in easing the inspection of extension 202 headers by middleboxes. There is further work required in this area. 203 Some issues that are left unresolved beyond this document include 204 o There can be an arbitrary number of extension headers. 205 o Extension headers must be processed in the order they appear. 206 o Extension headers may alter the processing of the payload itself, 207 and hence the packet may not be processed properly without 208 knowledge of said header. 210 7. IANA Considerations 212 This document does not require any IANA actions. 214 8. Security Considerations 216 This document proposes a standard format for the IPv6 extension 217 headers so that intermediate nodes that do not understand the 218 contents of these headers can look past them. Intermediate nodes, 219 such as firewalls, skipping over unknown headers might end up 220 allowing the setup of a covert channel from the outside of the 221 firewall to the inside using the data field(s) of the unknown 222 extension headers. 224 9. Acknowledgements 226 The authors would like to thank Albert Manfredi, Bob Hinden, Brian 227 Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela, 228 Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel 229 Halpern, Ran Atkinson and Steven Blake for their reviews and 230 suggestions that made this document better. 232 10. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 238 (IPv6) Specification", RFC 2460, December 1998. 240 Authors' Addresses 242 Suresh Krishnan 243 Ericsson 244 8400 Decarie Blvd. 245 Town of Mount Royal, QC 246 Canada 248 Phone: +1 514 345 7900 x42871 249 Email: suresh.krishnan@ericsson.com 251 james woodyatt 252 Apple Inc. 253 1 Infinite Loop 254 Cupertino, CA 95014 255 US 257 Email: jhw@apple.com 259 Erik Kline 260 Google 261 604 Arizona Avenue 262 Santa Monica, CA 90401 263 US 265 Phone: +1 310 460 4080 266 Email: ek@google.com 268 James Hoagland 269 Symantec Corporation 270 350 Ellis St. 271 Mountain View, CA 94043 272 US 274 Email: Jim_Hoagland@symantec.com 275 URI: http://symantec.com/ 277 Manav Bhatia 278 Alcatel-Lucent 279 Bangalore 280 India 282 Email: manav.bhatia@alcatel-lucent.com