idnits 2.17.00 (12 Aug 2021) /tmp/idnits15831/draft-pfeifer-6man-exthdr-res-01.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 date (September 11, 2011) is 3905 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-6man-exthdr has been published as RFC 6564 ** 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 Internet Engineering Task Force H. Pfeifer, Ed. 3 Internet-Draft Protocol Labs 4 Intended status: Standards Track September 11, 2011 5 Expires: March 14, 2012 7 IPv6 Extension Headers Reserved Space 8 draft-pfeifer-6man-exthdr-res-01.txt 10 Abstract 12 This document specify a mechanism to allow IPv6 stack implementation 13 to parse upcoming IPv6 extension header by reserving a small range of 14 protocol numbers for well defined IPv6 extension headers. IPv6 stack 15 implementors can code these range into their network stack a priori. 16 These reserved range provide an guarantee that a given next header is 17 a well formed extension header and not a next layer protocol. 18 Operators, companies, vendors et cetera are in the ability to deploy 19 and test not standardized extension headers without modifying every 20 middle box parsing the complete extension header chain in between. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on March 14, 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 BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Extension Header Encoding . . . . . . . . . . . . . . . . . . . 4 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 70 Appendix A. Implementation Example . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 Optional IPv6 protocol information are encoded in extension header 76 between the basic IPv6 header and the next layer protocol. Next 77 layer protocols such as TCP or UDP are encoded in a non uniform 78 manner. Network stacks that process the extension header chain are 79 required to know the exact encoding of all stagged headers until the 80 required next layer protocol is detected. If a unknown protocol or 81 extension header lies between the processing must be stopped. 83 Extension header are normally not processed on intermediate nodes 84 [RFC2460]. Intermediate nodes are urged to not examine or process 85 any extension header. One exception is is the hop-by-hop options 86 header which must be processed. Sometimes nodes along a packet's 87 delivery path are required to parse the complete extension header 88 chain to analyze the transport layer protocol. Middleboxes which 89 analyze the transport protocol header are the most prominent example. 90 Firewalls or network proxies are the most prominent examples. Middle 91 boxes have no possibility to resolve this circumstance cleanly. 92 Firewalls are likely to drop the packet. 94 End-boxed following [RFC2460] generate a ICMP Parameter Problem 95 message if an unknown extension header is detected. Providing the 96 sender enough information to resend the packet without the extension 97 header. 99 [I-D.ietf-6man-exthdr] defines a standard format to unify the layout 100 of IPv6 extension header and advised to use the IPv6 Destination 101 Options Header. Thus providing a way that future extensions are 102 encoded in a consistent manner. This is the first part to address 103 this unlucky fact. The second half of the problem lies in the fact 104 that the next header space is shared with the protocol number. 105 Network stack cannot differentiate if an unknown code-point declaring 106 an extension header or an protocol. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 2. Overview 116 This mechanism provide middle boxes the chance to process up to now 117 new extension header and simultaneous do not constrain the 118 possibility to introduce new extension header in future by reserving 119 a small fraction of protocol number space. 121 Future IPv6 extensions which cannot encoded in one of the existing 122 extension header MUST follow the encoding specification in 123 [I-D.ietf-6man-exthdr]. Upcoming standardized extension header 124 following the proposal MUST be reserved from this space. Network 125 stacks are provided with a guarantee that these extension headers 126 follow the specification. 128 Currently 60% of the space is already allocated. Thus to be 129 conservative a good compromise is to reserve the range between 245 130 and 252 (7). This leave space for 98 new next layer protocols, 98 131 extension header not following the proposal or any combination of 132 both. Upcoming standardized extension header following the proposal 133 MUST be reserved from this space. 135 Providing an guarantee of the encoding makes it possible that vendors 136 and other parties implement proprietary extension header without 137 standardization and wait years of enrollment of new middle-boxes 138 supporting the new extension header. 140 3. Extension Header Encoding 142 The following figure illustrate the format of the unified extension 143 header format. It will be removed if [I-D.ietf-6man-exthdr] is 144 approved. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Next Header | Hdr Ext Len | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 151 | | 152 . . 153 . Header Specific Data . 154 . . 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Next Header 8-bit selector. Identifies the type of header 159 immediately following the Extension header. 160 Uses the same values as the IPv4 Protocol 161 field. 162 Hdr Ext Len 8-bit unsigned integer. Length of the 163 Extension header in 8-octet units, not 164 including the first 8 octets. 165 Header Specific Variable length. Fields specific to the 166 Data extension header 168 Uniform IPv6 Extension Header 170 Figure 1 172 4. Acknowledgements 174 The author thank Suresh Krishnan, James Woodyatt, Erik Kline, James 175 Hoagland, Manav Bhatia and all other people involved in 176 [I-D.ietf-6man-exthdr]. 178 5. IANA Considerations 180 This document includes a request to IANA. The editors of this draft 181 request the protocol number 245 till 252 be reserved for uniform 182 formated IPv6 extension header 184 6. Security Considerations 186 Filled later 188 7. Normative References 190 [I-D.ietf-6man-exthdr] 191 Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 192 M. Bhatia, "An uniform format for IPv6 extension headers", 193 draft-ietf-6man-exthdr-04 (work in progress), July 2011. 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 199 (IPv6) Specification", RFC 2460, December 1998. 201 Appendix A. Implementation Example 203 The following patch applied on net-next-2.6 add support for the code- 204 point reservation. 206 diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c 207 index 14ed0a9..d7f2e97 100644 208 --- a/net/ipv6/exthdrs_core.c 209 +++ b/net/ipv6/exthdrs_core.c 210 @@ -4,6 +4,9 @@ 211 */ 212 #include 214 +#define IP6_EXTHDR_RESERVED_MIN 245 215 +#define IP6_EXTHDR_RESERVED_MAX 252 216 + 217 /* 218 * find out if nxthdr is a well-known extension header or a protocol 219 */ 220 @@ -18,7 +21,8 @@ int ipv6_ext_hdr(u8 nexthdr) 221 (nexthdr == NEXTHDR_FRAGMENT) || 222 (nexthdr == NEXTHDR_AUTH) || 223 (nexthdr == NEXTHDR_NONE) || 224 - (nexthdr == NEXTHDR_DEST); 225 + (nexthdr == NEXTHDR_DEST) || 226 + (nexthdr >= IP6_EXTHDR_RESERVED_MIN && 227 + nexthdr <= IP6_EXTHDR_RESERVED_MAX); 228 } 230 Figure 2 232 Author's Address 234 Hagen Paul Pfeifer (editor) 235 Protocol Labs 236 Hofmannstr. 19 237 81379, Munich 238 Germany 240 Phone: +49 174 5455 209 241 Email: hagen.pfeifer@protocollabs.com 242 URI: http://www.protocollabs.com