idnits 2.17.1 draft-bhatia-6man-update-ipv6-ext-hdr-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2010) is 4966 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) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) 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 Manav Bhatia 3 Internet Draft Alcatel-Lucent 4 Intended status: Standards Track 5 Expires: March, 2011 September 2010 7 Standardizing IPv6 Extension Header Definition 9 draft-bhatia-6man-update-ipv6-ext-hdr-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance 14 with the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as "work 25 in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described 47 in Section 4.e of the Trust Legal Provisions and are provided 48 without warranty as described in the Simplified BSD License. 50 Abstract 52 In IPv6, optional internet-layer information is encoded in 53 separate headers that may be placed between the IPv6 header and 54 the upper-layer header in a packet. There are a small number of 55 such extension headers, each identified by a distinct Next 56 Header value. However, it presents no backward compatible way 57 for incrementally introducing new IPv6 extension headers inside 58 the network. 60 Additionally since there is no standard format for extension 61 headers, it becomes impossible for intermediaries that want to 62 deep inspect the packet to parse an incoming packet which 63 carries an extension header that it does not recognize. 65 This document attempts to standardize the IPv6 extension header 66 format to fix these issues. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 71 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 72 "OPTIONAL" in this document are to be interpreted as described 73 in RFC 2119. [RFC2119] 75 Table of Contents 77 1. Problem Definition............................................2 78 2. Standard IPv6 Extension Header Format.........................3 79 3. Incremental Deployments.......................................5 80 4. Intermediary Nodes............................................5 81 5. Security Considerations.......................................5 82 6. IANA Considerations...........................................5 83 7. References....................................................5 84 7.1. Normative References.....................................5 85 7.2. Informative References...................................5 87 1. Problem Definition 89 The IPv6 standard [RFC2460] defines extension headers that can 90 be used to encode optional internet layer information and are 91 placed between the IPv6 main header and the upper-layer header 92 of the packet. This helps in improving forwarding performance as 93 the intermediate routers only look at the IPv6 main header and 94 dont process the extension headers treating them as part of the 95 packet payload. 97 The architecture is very flexible for developing new extension 98 headers for future uses as needed. New extension headers 99 [RFC3775] can be defined and used without changing the IPv6 main 100 header. 102 [RFC2460] allows us to chain multiple extension headers by using 103 the Next Header field. The Next Header field indicates to the 104 router which extension header to expect next. If there are no 105 more extension headers, the next header field indicates the 106 upper layer header (TCP, UDP, etc). 108 [RFC2460] further states that an end node that comes across an 109 unrecognized Next Header should discard that packet and send an 110 ICMP Parameter Problem message to the source of the packet, with 111 an ICMP code value of 1 ("unrecognized Next Header type 112 encountered") and the ICMP Pointer field containing the offset 113 of the unrecognized value within the original packet. 115 This creates a problem in incrementally introducing new IPv6 116 extension headers inside the network as all routers need to get 117 upgraded at the same time so that they don't discard packets. 118 This is cumbersome and is not always possible. 120 Another problem that exists is that if new extension headers are 121 defined, and if an intermediate device that wants to deep 122 inspect the packets is not aware of these extension headers, 123 then it may not be able to process the packet as it will not 124 know where the new unknown extension header ends and the next 125 one begins. 127 This document proposes to standardize the IPv6 extension header 128 format for fixing the above mentioned issues. 130 2. Standard IPv6 Extension Header Format 132 All IPv6 Extension Headers should have the format as described 133 in the following figure: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Next Header | Header Len | Hdr Options | | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 140 | | 141 | | 142 ~ Extension Header Specific Data ~ 143 | | 144 | | 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1 150 Next Header 152 8 bit selector that identifies the type of header immediately 153 following the Extension Header. Uses the same values as the IPv6 154 Next Header field [RFC2460]. 156 Header Len 158 8-bit selector that indicates the length in 8 octet units of the 159 extension header, not including the first 8 octets. 161 Hdr Options 163 8-bit selector where the highest two bits specify the action 164 that must be taken if the processing IPv6 node does not 165 recognize the extension header: 167 00 skip over this option and continue processing the header. 169 01 discard the packet. 171 10 discard the packet and, regardless of whether or not the 172 packet's Destination Address was a multicast address, send 173 an ICMP Parameter Problem, Code 1, message to the packet's 174 Source Address, pointing to the unrecognized value within 175 the original packet. 177 11 discard the packet and, only if the packet's Destination 178 Address was not a multicast address, send an ICMP 179 parameter Problem, Code 1, message to the packet's Source 180 Address, pointing to the unrecognized value within 181 the original packet. 183 3. Incremental Deployments 185 New extension headers can set the highest order bits in the 186 Header Options of the extension header to 00 so that the end 187 node can still process the original packet. This will obviously 188 only help if the end node can still function without being able 189 to understand the new extension header. An example of this is 190 [karp-non-ipsec-ospfv3-auth]. 192 4. Intermediary Nodes 194 Intermediaries that cannot recognize the new extension header 195 can look at the length of the extension header and skip as many 196 bytes and continue with the remaining packet if it so desires. 197 Additionally it MAY look at the Header Options and decide if it 198 wants to pass/drop the packet. 200 5. Security Considerations 202 This document introduces no new security threat that already 203 exists. 205 6. IANA Considerations 207 This document requires no action from IANA. 209 7. References 211 7.1. Normative References 213 [RFC2119] Bradner, S.,"Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997. 216 [RFC2460] Deering, S., et. al, "Internet Protocol, Version 6 217 (IPv6) Specification", RFC 2460, December 1998. 219 7.2. Informative References 221 [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, 222 June 2004. 224 [karp-non-ipsec-ospfv3-auth] Bhatia, M.," Non IPSec 225 Authentication mechanism for OSPFv3", Work in Progress 227 Author's Addresses 228 Manav Bhatia 229 Alcatel-Lucent 230 Bangalore 231 India 233 Phone: 234 Email: manav.bhatia@alcatel-lucent.com