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