idnits 2.17.1 draft-ietf-6man-exthdr-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 == Line 158 has weird spacing: '... within the o...' == 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 (December 17, 2010) is 4878 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 (~~), 3 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: June 20, 2011 Apple 6 E. Kline 7 Google 8 J. Hoagland 9 Symantec 10 M. Bhatia 11 Alcatel-Lucent 12 December 17, 2010 14 An uniform format for IPv6 extension headers 15 draft-ietf-6man-exthdr-01 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 a new 23 family of 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 June 20, 2011. 42 Copyright Notice 44 Copyright (c) 2010 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 1.1. Conventions used in this document . . . . . . . . . . . . . 3 61 2. Generic IPv6 Extension Header (GIEH) format . . . . . . . . . . 4 62 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 63 4. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. 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 defines 85 a standard format for a new family of IPv6 extension headers. 87 1.1. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Generic IPv6 Extension Header (GIEH) format 95 This document proposes a new family of IPv6 extension headers that 96 will be encoded in a consistent format so that it is possible for 97 intermediate nodes to skip over unknown extension headers and 98 continue to further process the header chain if they so desire. The 99 intention of the base IPv6 Specification [RFC2460] that destination 100 hosts not be permitted to skip unknown extension headers continues to 101 apply. One key advantage of using such a generic IPv6 extension 102 header is that it allows nodes to distinguish between unknown 103 extension headers and unknown upper layer protocols, which was not 104 possible earlier. Another one is that this generic extension header 105 conserves values in the IPv4 protocol numbers registry. 107 This documents requires the allocation of a single IP protocol number 108 for the Generic IPv6 extension header (GIEH), say TBA1. 109 Specifications of new extension headers SHOULD use this generic 110 extension header format whenever feasible. The generic extension 111 header will be identified by the value TBA1 occuring in the Next 112 Header field of the preceding extension header. The second octet 113 contains the length of the extension header. The third octet of the 114 GIEH contains a specific extension header type (that identifies the 115 actual extension header). All other data in the GIEH is type- 116 specific. 118 0 1 2 3 119 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 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Next Header | Hdr Ext Len | Specific Type | Hdr Options | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | | 124 . . 125 . Header Specific Data . 126 . . 127 | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Next Header 8-bit selector. Identifies the type of header 131 immediately following this Extension header. 132 Uses the same values as the IPv4 Protocol 133 field. 135 Hdr Ext Len 8-bit unsigned integer. Length of the 136 Extension header in 8-octet units, not 137 including the first 8 octets. 139 Specific Type 8-bit unsigned integer. The actual IPv6 140 extension header type. This will be allocated 141 from a new IANA registry. 143 Hdr Options 8-bit selector. The two most significant bits 144 specify the action that must be taken if the 145 processing IPv6 node does not recognize the 146 extension header: 148 00 - skip over this option and continue 149 processing the header. 151 01 - discard the packet. 153 10 - discard the packet and, regardless of 154 whether or not the packet's Destination 155 Address was a multicast address, send 156 an ICMP Parameter Problem, Code 1, message 157 to the packet's Source Address, pointing to 158 the unrecognized value within the original 159 packet. 161 11 - discard the packet and, only if the packet's 162 Destination Address was not a multicast 163 address, send an ICMP parameter Problem, 164 Code 1, message to the packet's Source 165 Address, pointing to the unrecognized value 166 within the original packet. 168 The other 6 bits in this field are reserved. They 169 MUST be set to zero on transmission and SHOULD be 170 ignored on reception. 172 Header Specific Variable length. Fields specific to the 173 Data extension header. This field MUST be padded 174 as required in order to ensure that the 175 complete GIEH is a multiple of 8 octets long. 177 Figure 1: Generic IPv6 Extension Header (GIEH) layout 179 3. Backward Compatibility 181 The scheme proposed in this document is not backward compatible with 182 all the currently defined IPv6 extension headers. It only applies to 183 newly defined extension headers. Specifically, the following 184 extension headers predate this document and do not follow the format 185 proposed in this document. 187 o IPv6 Hop-by-Hop Options Header 188 o IPv6 Routing Header 189 o IPv6 Fragment Header 190 o IPv6 Destination Options Header 192 4. Exceptions 194 The the Generic IPv6 extension header is generic enough that it is 195 suitable to use for most applications. However, it is possible that 196 the GIEH does not satisfy the requirements in all cases where new 197 extension headers are required. Hence, the existence of this generic 198 header does not necessarily preclude the definition of new 199 independent IPv6 extension headers. 201 5. Future work 203 This document proposes one step in easing the inspection of extension 204 headers by middleboxes. There is further work required in this area. 205 Some issues that are left unresolved beyond this document include 207 o There can be an arbitrary number of extension headers. 208 o Extension headers must be processed in the order they appear. 209 o Extension headers may alter the processing of the payload itself, 210 and hence the packet may not be processed properly without 211 knowledge of said header. 213 6. IANA Considerations 215 This document requests a single allocation from the IANA for this 216 generic IPv6 extension header type (TBA1) from the Assigned Internet 217 Protocol Numbers registry located at 218 http://www.iana.org/assignments/protocol-numbers. 220 This document also requests the creation of a new registry for GIEH 221 sub-types. The allocation policy for these subtypes is Standards 222 Action. 224 7. Security Considerations 226 This document proposes a standard format for the IPv6 extension 227 headers so that intermediate nodes that do not understand the 228 contents of these headers can look past them. Intermediate nodes, 229 such as firewalls, skipping over unknown headers might end up 230 allowing the setup of a covert channel from the outside of the 231 firewall to the inside using the data field(s) of the unknown 232 extension headers. 234 8. Acknowledgements 236 The authors would like to thank Albert Manfredi, Bob Hinden, Brian 237 Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela, 238 Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel 239 Halpern and Ran Atkinson for their reviews and suggestions that made 240 this document better. 242 9. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 248 (IPv6) Specification", RFC 2460, December 1998. 250 Authors' Addresses 252 Suresh Krishnan 253 Ericsson 254 8400 Decarie Blvd. 255 Town of Mount Royal, QC 256 Canada 258 Phone: +1 514 345 7900 x42871 259 Email: suresh.krishnan@ericsson.com 260 james woodyatt 261 Apple Inc. 262 1 Infinite Loop 263 Cupertino, CA 95014 264 US 266 Email: jhw@apple.com 268 Erik Kline 269 Google 270 604 Arizona Avenue 271 Santa Monica, CA 90401 272 US 274 Phone: +1 310 460 4080 275 Email: ek@google.com 277 James Hoagland 278 Symantec Corporation 279 350 Ellis St. 280 Mountain View, CA 94043 281 US 283 Email: Jim_Hoagland@symantec.com 284 URI: http://symantec.com/ 286 Manav Bhatia 287 Alcatel-Lucent 288 Bangalore 289 India 291 Email: manav.bhatia@alcatel-lucent.com