idnits 2.17.1 draft-krishnan-ipv6-exthdr-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 (March 7, 2010) is 5157 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 Intended status: Standards Track j h. woodyatt 5 Expires: September 8, 2010 Apple 6 E. Kline 7 Google 8 J. Hoagland 9 Symantec 10 March 7, 2010 12 An uniform format for IPv6 extension headers 13 draft-krishnan-ipv6-exthdr-08 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 defines a format for defining a new 21 family of IPv6 extension headers. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 8, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Conventions used in this document . . . . . . . . . . . . . 3 65 2. Generic IPv6 Extension Header (GIEH) format . . . . . . . . . . 4 66 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 67 4. Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 The base IPv6 standard [RFC2460] defines extension headers as an 78 expansion mechanism to carry optional internet layer information. 79 Extension headers, with the exception of the hop-by-hop options 80 header, are not usually processed on intermediate nodes. However, 81 some intermediate nodes such as firewalls, may need to look at the 82 transport layer header fields in order to make a decision to allow or 83 deny the packet. If new extension headers are defined and the 84 intermediate node is not aware of them, the intermediate node cannot 85 proceed further in the header chain since it does not know where the 86 unknown header ends and the next header begins. The main issue is 87 that the extension header format is not standardized and hence it is 88 not possible to skip past the unknown header. This document defines 89 a standard format for a new family of IPv6 extension headers. 91 1.1. Conventions used in this document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Generic IPv6 Extension Header (GIEH) format 99 This document proposes a new family of IPv6 extension headers that 100 will be encoded in a consistent format so that it is possible for 101 intermediate nodes to skip over unknown extension headers and 102 continue to further process the header chain if they so desire. The 103 intention of the base IPv6 Specification [RFC2460] that destination 104 hosts not be permitted to skip unknown extension headers continues to 105 apply. One key advantage of using such a generic IPv6 extension 106 header is that it allows nodes to distinguish between unknown 107 extension headers and unknown upper layer protocols, which was not 108 possible earlier. Another one is that this generic extension header 109 conserves values in the IPv4 protocol numbers registry. 111 This documents requires the allocation of a single IP protocol number 112 for the Generic IPv6 extension header (GIEH), say TBA1. 113 Specifications of new extension headers SHOULD use this generic 114 extension header format whenever feasible. The generic extension 115 header will be identified by the value TBA1 occuring in the Next 116 Header field of the preceding extension header. The second octet 117 contains the length of the extension header. The third octet of the 118 GIEH contains a specific extension header type (that identifies the 119 actual extension header). All other data in the GIEH is type- 120 specific. 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Next Header | Hdr Ext Len | Specific Type | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 127 | | 128 . . 129 . Header Specific Data . 130 . . 131 | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Next Header 8-bit selector. Identifies the type of header 135 immediately following this Extension header. 136 Uses the same values as the IPv4 Protocol 137 field. 138 Hdr Ext Len 8-bit unsigned integer. Length of the 139 Extension header in 8-octet units, not 140 including the first 8 octets. 141 Specific Type 8-bit unsigned integer. The actual IPv6 142 extension header type. This will be allocated 143 from a new IANA registry. 144 Header Specific Variable length. Fields specific to the 145 Data extension header. This field MUST be padded 146 as required in order to ensure that the 147 complete GIEH is a multiple of 8 octets long. 149 Figure 1: Generic IPv6 Extension Header (GIEH) layout 151 3. Backward Compatibility 153 The scheme proposed in this document is not backward compatible with 154 all the currently defined IPv6 extension headers. It only applies to 155 newly defined extension headers. Specifically, the following 156 extension headers predate this document and do not follow the format 157 proposed in this document. 159 o IPv6 Hop-by-Hop Options Header 160 o IPv6 Routing Header 161 o IPv6 Fragment Header 162 o IPv6 Destination Options Header 164 4. Exceptions 166 The the Generic IPv6 extension header is generic enough that it is 167 suitable to use for most applications. However, it is possible that 168 the GIEH does not satisfy the requirements in all cases where new 169 extension headers are required. Hence, the existence of this generic 170 header does not necessarily preclude the definition of new 171 independent IPv6 extension headers. 173 5. Future work 175 This document proposes one step in easing the inspection of extension 176 headers by middleboxes. There is further work required in this area. 177 Some issues that are left unresolved beyond this document include 179 o There can be an arbitrary number of extension headers. 180 o Extension headers must be processed in the order they appear. 181 o Extension headers may alter the processing of the payload itself, 182 and hence the packet may not be processed properly without 183 knowledge of said header. 185 6. IANA Considerations 187 This document requests a single allocation from the IANA for this 188 generic IPv6 extension header type (TBA1) from the Assigned Internet 189 Protocol Numbers registry located at 190 http://www.iana.org/assignments/protocol-numbers. 192 This document also requests the creation of a new registry for GIEH 193 sub-types. The allocation policy for these subtypes is Standards 194 Action. 196 7. Security Considerations 198 This document proposes a standard format for the IPv6 extension 199 headers so that intermediate nodes that do not understand the 200 contents of these headers can look past them. Intermediate nodes, 201 such as firewalls, skipping over unknown headers might end up 202 allowing the setup of a covert channel from the outside of the 203 firewall to the inside using the data field(s) of the unknown 204 extension headers. 206 8. Acknowledgements 208 The authors would like to thank Albert Manfredi, Bob Hinden, Brian 209 Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela, 210 Tatuya Jinmei, Thomas Narten, Vishwas Manral and Alfred Hoenes for 211 their reviews and suggestions that made this document better. 213 9. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 219 (IPv6) Specification", RFC 2460, December 1998. 221 Authors' Addresses 223 Suresh Krishnan 224 Ericsson 225 8400 Decarie Blvd. 226 Town of Mount Royal, QC 227 Canada 229 Phone: +1 514 345 7900 x42871 230 Email: suresh.krishnan@ericsson.com 232 james woodyatt 233 Apple Inc. 234 1 Infinite Loop 235 Cupertino, CA 95014 236 US 238 Email: jhw@apple.com 239 Erik Kline 240 Google 241 604 Arizona Avenue 242 Santa Monica, CA 90401 243 US 245 Phone: +1 310 460 4080 246 Email: ek@google.com 248 James Hoagland 249 Symantec Corporation 250 350 Ellis St. 251 Mountain View, CA 94043 252 US 254 Email: Jim_Hoagland@symantec.com 255 URI: http://symantec.com/