idnits 2.17.1 draft-zhang-6man-offset-option-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: ---------------------------------------------------------------------------- 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 9, 2011) is 4614 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zhang 3 Internet-Draft S. Jiang 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: March 12, 2012 B. Carpenter 6 Univ. of Auckland 7 September 9, 2011 9 An Offset Indicating Option for IPv6 10 draft-zhang-6man-offset-option-00 12 Abstract 14 This document defines an Offset Indicating option (OI option) 15 encapsulated within the IPv6 Hop-by-Hop Options header. An OI option 16 can provide offset information to locate the end of the IPv6 header 17 chain so that a node receiving an IPv6 packet is able to skip over 18 the IP header chain and access the transport header or other protocol 19 data unit directly. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 12, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 57 3. Format of the Offset Indicating option . . . . . . . . . . . . 3 58 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 According to [RFC2460], when a node intends to access the payload of 69 an IPv6 packet, it needs to parse the extension headers one by one 70 until it reaches the end of the header chain. This approach may be 71 inefficient for nodes which have no interest in the extension headers 72 and intend to quickly access the payload of IPv6 packets. 74 A common case is any form of flow classification requiring access to 75 the basic IP header 5-tuple {destination address, source address, 76 protocol, destination port, source port}. The last three elements 77 are only available by following the extension header chain to its 78 end. A method is needed to short-circuit this process. 80 A brief discussion of this issue from a security standpoint is 81 provided in Section 2.1.9.2 of [RFC4942]. In addition, most existing 82 firewall implementations have the capability to verify the 83 correctness of IP headers. Therefore, in some cases, it may be more 84 efficient for the equipment behind a firewall, such as a host or a 85 deep packet inspection device, to skip over the extension headers of 86 the IP packets it receives and access the payload directly. 88 This document addresses this issue by introducing an Offset 89 Indicating option (OI option for short) which indicates the end of 90 the header chain. The option is transferred in the Hop-by-Hop 91 Options header. According to [RFC2460], the Hop-by-Hop Options 92 header should be located at the beginning of the header chain. 93 Therefore, if necessary, a node receiving an IPv6 packet can jump 94 over the whole header chain in a single step to directly access the 95 transport header or other protocol data unit. 97 This option is an optimization option for certain routers. It may be 98 safely ignored. Hence, it does not create performance degradation. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Format of the Offset Indicating option 108 The format of the Offset Indicating option (OI) option is described 109 in Figure 1. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Option Type | Opt Data Len | Offset | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | NH after Jump | 117 +-+-+-+-+-+-+-+-+ 118 Figure 1. Option Format 120 Option Type: 8 bits. The value is TBD1. 122 Note to RFC Editor: please replace TBD1 with the value assigned by 123 IANA and delete this note. 125 Opt Data Len: as defined in [RFC2460]. 127 Offset: 16 bits. Indicates the distance (in octets) from the end of 128 the option to the end of the header chain. 130 NH (Next Header) after Jump: 8 bits. Indicates the type of the 131 transport header or other protocol data unit after the header chain. 132 This MUST equal the Next Header value in the last Extension Header in 133 the packet. 135 4. Processing Rules 137 Because the options within a header must be processed strictly in the 138 order that they appear, the OI option is RECOMMENDED to be the first 139 option within the Hop-by-Hop Options header. This arrangement will 140 maximize the effect of optimization for those routers that use it. 142 IPv6 source nodes SHOULD insert this option in every packet that 143 contains at least one extension header of any kind, in order to 144 maximise its usefulness. However, it MUST NOT be inserted in packets 145 that include a Fragment Header, to avoid the case where the offset 146 points beyond the end of the first fragment. In any case, 147 performance optimisation is impossible in the case of fragmented 148 packets. 150 As a sub-option of the Hop-by-Hop extension header, this option has 151 an alignment requirement of 4n + 2. (See Section 4.2 of [RFC2460] 152 for discussion of option alignment.) If this option is located first 153 within the Hop-by-Hop header, the alignment reqirement is met 154 naturally; otherwise the host stack that assembles the IPv6 header 155 needs to meet the alignment requirement according to the context by 156 inserting padding options. 158 The OI option is defined on the basis that the size of extension 159 headers does not change en-route. However, if a future extension 160 header type allows an intermediate device to add additional 161 information in the IP extension header chain, this device MUST also 162 update the value of the Offset field to point to the new position of 163 the payload header. 165 If an intermediate device detects that the OI option does not point 166 to a valid transport header, the IPv6 packet MUST be discarded. 168 5. Security Considerations 170 The OI option provides a method for nodes which have no interest in 171 parsing the header chain to quickly process IP packets. Because 172 transport layer security protocols do not cover extension headers, 173 and the information in the IPv6 header and the OI option is 174 sufficient in generating the pseudo-header for upper layer protocols, 175 the skip of extension headers will not impact the security 176 verification performed by transport layer security protocols. 177 However, in IPsec the situation is a little different. Because the 178 ESP header [RFC4303] or the AH header [RFC4302] consist of critical 179 information to process the IPsec packet and the extension headers 180 after the ESP or AH header may have to be authenticated or encrypted, 181 these extension headers cannot be skipped over. Therefore, a IPsec 182 implementation MUST NOT skip to the end of the header chain under the 183 instruction of the OI option. 185 This specification disallows use of the OI option in fragmented 186 packets. In addition to efficiency considerations, this prevents the 187 option from becoming a vector for a buffer overflow attack. 189 Attackers cannot use the OI option to hide any undesired information 190 in the IPv6 header, because this option is only an optional 191 indication for intermediate devices that do not in any case wish to 192 inspect such information. Security devices may simply ignore this 193 indication and verify every extension header in the chain. 195 6. IANA Considerations 197 IANA is requested to assign the IPv6 Option Type TBD1 for the Offset 198 Indicating Option and record it in the IPv6 Destination Options and 199 Hop-by-Hop Options registry. 201 In accordance with Section 4.2 of [RFC2460], this option type has the 202 two most significant bits set to 00 (skip if unrecognized) and the 203 third-highest-order bit set to 1 (option data may change en-route). 205 This is in case a future IPv6 extension header type may be defined 206 whose size may change en-route, requiring the Offset value to be 207 updated. 209 Note to RFC Editor: please replace TBD1 with the value assigned by 210 IANA and delete this note. 212 7. References 214 7.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 219 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 220 (IPv6) Specification", RFC 2460, December 1998. 222 7.2. Informative References 224 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 225 December 2005. 227 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 228 RFC 4303, December 2005. 230 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 231 Co-existence Security Considerations", RFC 4942, 232 September 2007. 234 Authors' Addresses 236 Dacheng Zhang 237 Huawei Technologies Co., Ltd 238 Huawei Building, No.3 Xinxi Rd., 239 Shang-Di Information Industry Base, Hai-Dian District, Beijing 240 P.R. China 242 Email: zhangdacheng@huawei.com 243 Sheng Jiang 244 Huawei Technologies Co., Ltd 245 Huawei Building, No.3 Xinxi Rd., 246 Shang-Di Information Industry Base, Hai-Dian District, Beijing 247 P.R. China 249 Email: jiangsheng@huawei.com 251 Brian Carpenter 252 Department of Computer Science 253 University of Auckland 254 PB 92019 255 Auckland, 1142 256 New Zealand 258 Email: brian.e.carpenter@gmail.com