idnits 2.17.1 draft-zhang-6man-offset-option-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 -- The document date (September 16, 2011) is 4605 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 19, 2012 B. Carpenter 6 Univ. of Auckland 7 September 16, 2011 9 An Offset Indicating Option for IPv6 10 draft-zhang-6man-offset-option-01 12 Abstract 14 This document defines an Offset Indicating option (OI option) 15 encapsulated within an IPv6 Options header. An OI option can provide 16 offset information to locate the end of the IPv6 header chain so that 17 a node receiving an IPv6 packet is able to skip over the IP header 18 chain and access the transport header or other protocol data unit 19 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 19, 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 . . . . . . . . . . . . . . . . . . . . . 4 57 3. Format of the Offset Indicating option . . . . . . . . . . . . 4 58 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 According to [RFC2460], when a node intends to access the payload of 70 an IPv6 packet, it needs to parse the extension headers one by one 71 until it reaches the end of the header chain. This approach may be 72 inefficient for nodes which have no interest in the extension headers 73 and intend to quickly access the payload of IPv6 packets. 75 A common case is any form of flow classification requiring access to 76 the basic IP header 5-tuple {destination address, source address, 77 protocol, destination port, source port}. The last three elements 78 are only available by following the extension header chain to its 79 end. This could be required for various forms of quality of service 80 support or for flow logging purposes. Another case would be any form 81 of deep packet inspection requiring rapid access to the payload, 82 which also requires skipping over the header chain. If packets must 83 be processed at line speed, this can be a significant performance 84 issue. A method is needed to short-circuit this process. 86 A brief discussion of this issue from a security standpoint is 87 provided in Section 2.1.9.2 of [RFC4942]. In addition, most existing 88 firewall implementations have the capability to verify the 89 correctness of IP headers. Therefore, in some cases, it may be more 90 efficient for the equipment behind a firewall, such as a host or a 91 deep packet inspection device, to skip over the extension headers of 92 the IP packets it receives and access the payload directly. 94 This document addresses this issue by introducing an Offset 95 Indicating option (OI option for short) which indicates the end of 96 the header chain. The option is transferred in an IPv6 Options 97 header. If there is an existing Hop-by-Hop Options header, the OI 98 option will be in it. Otherwise, it will be in a Destination Options 99 header. According to the recommendations in [RFC2460], this will 100 always place the OI option at the beginning of the header chain. 101 Therefore, if necessary, a node receiving an IPv6 packet can jump 102 over the whole header chain in a single step to directly access the 103 transport header or other protocol data unit. 105 This option is an optimization option for certain forwarding nodes. 106 It may be safely ignored by nodes that have no interest in the header 107 chain. Hence, it does not create any performance degradation. In 108 particular, unless there is a Hop-by-Hop Options header for some 109 other reason, it does not create any overhead for simple forwarding 110 nodes. 112 2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Format of the Offset Indicating option 120 The format of the Offset Indicating option (OI) option is described 121 in Figure 1. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Option Type | Opt Data Len | Offset | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | NH after Jump | 129 +-+-+-+-+-+-+-+-+ 130 Figure 1. Option Format 132 Option Type: 8 bits. The value is TBD1. 134 Note to RFC Editor: please replace TBD1 with the value assigned by 135 IANA and delete this note. 137 Opt Data Len: as defined in [RFC2460]. 139 Offset: 16 bits. Indicates the distance (in octets) from the end of 140 the option to the end of the header chain. 142 NH (Next Header) after Jump: 8 bits. Indicates the type of the 143 transport header or other protocol data unit after the header chain. 144 This MUST equal the Next Header value in the last Extension Header in 145 the packet. 147 4. Processing Rules 149 IPv6 source nodes SHOULD insert this option in every packet that 150 contains at least one extension header of any kind, in order to 151 maximise its usefulness. However, it MUST NOT be inserted in packets 152 that include a Fragment Header, to avoid the case where the offset 153 points beyond the end of the first fragment. In any case, 154 performance optimisation is impossible in the case of fragmented 155 packets. 157 Because the options within a header must be processed strictly in the 158 order that they appear, the OI option is RECOMMENDED to be the first 159 option within an Options header. This arrangement will maximize the 160 effect of optimization for those routers that use it. 162 A Hop-by-Hop Options header MUST NOT be created solely for the 163 purpose of carrying the OI option. If and only if the packet 164 contains a Hop-by-Hop Options header for some other reason, the OI 165 option is placed in it. Otherwise it is placed in a Destination 166 Options header. 168 This option has an alignment requirement of 4n + 2. (See Section 4.2 169 of [RFC2460] for discussion of option alignment.) If this option is 170 located first within the Options header, the alignment reqirement is 171 met naturally; otherwise the host stack that assembles the IPv6 172 header needs to meet the alignment requirement according to the 173 context by inserting padding options. 175 The OI option is defined on the basis that the size of extension 176 headers does not change en-route. However, if a future extension 177 header type allows an intermediate device to add additional 178 information in the IP extension header chain, this device MUST also 179 update the value of the Offset field to point to the new position of 180 the payload header. 182 If an intermediate device detects that the OI option does not point 183 to a valid transport header, the IPv6 packet MUST be discarded. 185 5. Security Considerations 187 The OI option provides a method for nodes which have no interest in 188 parsing the header chain to quickly process IP packets. Because 189 transport layer security protocols do not cover extension headers, 190 and the information in the IPv6 header is sufficient to generate the 191 pseudo-header for upper layer protocols, the skipping of extension 192 headers will not impact the security verification performed by 193 transport layer security protocols. However, in IPsec the situation 194 is a little different. Because the ESP header [RFC4303] or the AH 195 header [RFC4302] consist of critical information to process the IPsec 196 packet and the extension headers after the ESP or AH header may have 197 to be authenticated or encrypted, these extension headers cannot be 198 skipped over. Therefore, a IPsec implementation MUST NOT skip to the 199 end of the header chain under the instruction of the OI option. 201 This specification disallows use of the OI option in fragmented 202 packets. In addition to efficiency considerations, this prevents the 203 option from becoming a vector for a buffer overflow attack. 205 Attackers cannot use the OI option to hide any undesired information 206 in the IPv6 header, because this option is only an optional 207 indication for intermediate devices that do not in any case wish to 208 inspect such information. Security devices may simply ignore this 209 indication and verify every extension header in the chain. 211 6. IANA Considerations 213 IANA is requested to assign the IPv6 Option Type TBD1 for the Offset 214 Indicating Option and record it in the IPv6 Destination Options and 215 Hop-by-Hop Options registry. 217 In accordance with Section 4.2 of [RFC2460], this option type has the 218 two most significant bits set to 00 (skip if unrecognized) and the 219 third-highest-order bit set to 1 (option data may change en-route). 220 This is in case a future IPv6 extension header type may be defined 221 whose size may change en-route, requiring the Offset value to be 222 updated. 224 Note to RFC Editor: please replace TBD1 with the value assigned by 225 IANA and delete this note. 227 7. Acknowledgements 229 Valuable comments on this draft were made by Thomas Narten. 231 8. References 233 8.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 239 (IPv6) Specification", RFC 2460, December 1998. 241 8.2. Informative References 243 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 244 December 2005. 246 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 247 RFC 4303, December 2005. 249 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 250 Co-existence Security Considerations", RFC 4942, 251 September 2007. 253 Authors' Addresses 255 Dacheng Zhang 256 Huawei Technologies Co., Ltd 257 Huawei Building, No.3 Xinxi Rd., 258 Shang-Di Information Industry Base, Hai-Dian District, Beijing 259 P.R. China 261 Email: zhangdacheng@huawei.com 263 Sheng Jiang 264 Huawei Technologies Co., Ltd 265 Huawei Building, No.3 Xinxi Rd., 266 Shang-Di Information Industry Base, Hai-Dian District, Beijing 267 P.R. China 269 Email: jiangsheng@huawei.com 271 Brian Carpenter 272 Department of Computer Science 273 University of Auckland 274 PB 92019 275 Auckland, 1142 276 New Zealand 278 Email: brian.e.carpenter@gmail.com