idnits 2.17.00 (12 Aug 2021) /tmp/idnits4273/draft-wkumari-long-headers-02.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 (October 21, 2013) is 3134 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2474' is defined on line 336, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-oversized-header-chain has been published as RFC 7112 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN W. Kumari 3 Internet-Draft Google 4 Intended status: Best Current Practice J. Jaeggli 5 Expires: April 24, 2014 Zynga 6 R. Bonica 7 Juniper Networks 8 October 21, 2013 10 Operational Issues Associated With Long IPv6 Header Chains 11 draft-wkumari-long-headers-02 13 Abstract 15 This memo specifies requirements for IPv6 forwarders as they process 16 packets with long header chains. It also provides guidance for 17 application developers whose applications might rely on long headers 18 chains. 20 As background, this memo explains how many ASIC-based IPv6 forwarders 21 process packets and why processing of packets with long header chains 22 might be problematic. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 24, 2014. 47 Copyright Notice 48 Copyright (c) 2013 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 Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Forwarder Information Requirements . . . . . . . . . . . . . 4 66 3. Requirements For IPv6 Forwarders . . . . . . . . . . . . . . 5 67 4. Recommendations For Application Developers . . . . . . . . . 7 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 IPv6 [RFC2460] forwarders can acquire information from the following 80 sources: 82 o The IPv6 header 84 o One or more IPv6 extension headers 86 o An upper-layer header 88 Section 2 of this document explains how IPv6 forwarders use 89 information from the IPv6 header and IPv6 extension headers to 90 provide traditional forwarding services. It also explains how IPv6 91 forwarders use information from the upper-layer header to provide 92 enhanced forwarding services. 94 When a software-based forwarder processes an IPv6 datagram, it parses 95 the header chain, regardless of its length, acquires the required 96 information and makes a forwarding decision. Typically, software- 97 based forwarders process a relatively small number of packets per 98 second. Therefore, they can perform the above mentioned procedure 99 within the constraints of their processing budget. 101 By contrast, ASIC-based forwarders process many more packets per 102 second. In order to fulfill this requirement, ASIC-based forwarders 103 copy a fixed number of bytes from the beginning of the packet to on- 104 chip memory. Forwarders do this because they can access on-chip 105 memory much more quickly than they can access off-chip memory. Once 106 the beginning of the packet has been transferred to on-chip memory, 107 subsequent processing can proceed very quickly. 109 The act of copying bytes from the beginning of a packet to on-chip 110 memory consumes: 112 o Processor cycles 114 o On-chip memory 116 o Wall-time 118 Therefore, the number of bytes copied to on-chip memory must be 119 chosen wisely. If a forwarder copies more bytes than it needs, it 120 wastes resources and adversely impacts performance. If it copies too 121 few bytes, it may not have sufficient information to make a correct 122 forwarding decision. 124 The IPv6 header chain is a variable-length data structure, whose size 125 can exceed 64 kilobytes. However, packets with header chains 126 exceeding 256 bytes are rarely observed on the Internet. Therefore, 127 most ASIC-based forwarders copy a relatively small number of bytes 128 from the beginning of a packet into on-chip memory. While this small 129 number varies from platform to platform, it is generally much closer 130 to 256 bytes than it is to 64 kilobytes. 132 IPv6 forwarders MUST behave in a predictable manner when they process 133 a packet whose header chain length exceeds the number of bytes copied 134 to on-chip memory. Section 3 of this memo defines required 135 behaviors. 137 Application developers should be aware of how ASIC-based forwarders 138 process packets with long extension header chains. Therefore, 139 Section 4 of this document provides guidance to application 140 developers. 142 1.1. Terminology 143 For the purposes of this document, the terms "header chain" and 144 "upper-layer" header are used as defined in 145 [I-D.ietf-6man-oversized-header-chain]. 147 This document also introduces the following terms: 149 o forwarding service - a service that accepts a packet from one 150 interface and forwards it through another 152 o traditional forwarding service - a forwarding service in which all 153 parameters to the forwarding algorithm are drawn from the IPv6 154 header, the hop-by-hop extension header, and the routing extension 155 header 157 o enhanced forwarding service - a forwarding service in which 158 parameters to the forwarding algorithm can be drawn from any 159 portion of the IPv6 header chain 161 2. Forwarder Information Requirements 163 When an IPv6 forwarder provides traditional forwarding services, it 164 extracts all information required by the forwarding algorithm from 165 the IPv6 header, the hop-by-hop extension header (if present), and 166 the routing extension header (if present). In the nominal case, the 167 IPv6 header contains all information required by the forwarding 168 algorithm. However, the hop-by-hop and routing extension headers can 169 also impact forwarding behavior. 171 Section 4.2 of [RFC2460] explains how the hop-by-hop extension header 172 impacts forwarding behavior. When the forwarder processes a hop-by- 173 hop extension header, it examines each option contained by the 174 header. If forwarder encounters an unrecognized hop-by-hop option, 175 and the high-order bits of the option type are "00", the forwarder 176 skips over the option and continues to process subsequent options. 177 However, if an forwarder encounters an unrecognized option, and the 178 high-order bits of the option type are "01", "10" or "11", the 179 forwarder discards the packet. 181 Section 4.4 of [RFC2460] explains how the routing extension header 182 impacts forwarding behavior. When the forwarder processes a packet 183 whose destination address is local to itself, it scans the header 184 chain, searching for a routing extension header. If the packet 185 contains a routing extension header and the forwarder recognizes the 186 routing header type, it processes the header. If the forwarder does 187 not recognize the routing header type, the required behavior depends 188 upon the Segments Left field. If the Segments Left field is equal to 189 zero, the forwarder ignores the routing extension header. Otherwise, 190 the forwarder discards the packet. [RFC6275] and [RFC6554] describe 191 currently defined routing extension header types. 193 Some IPv6 forwarders provide enhanced forwarding services, such as 194 firewall filtering, rate limiting and load balancing. In order to 195 provide these services, the forwarder requires access to an upper 196 layer header. The following are examples of enhanced services that 197 require the forwarder to examine the upper layer header: 199 o Discard all packets directed to TCP port 25 201 o Rate limit packets destined for a particular address whose payload 202 is TCP and have the TCP SYN bit set 204 o Load balance packets across parallel links so that all packet 205 belonging to particular TCP session traverse the same link 207 3. Requirements For IPv6 Forwarders 209 The following requirements apply to all IPv6 forwarders: 211 o REQ-1: An IPv6 forwarder SHOULD NOT discard a valid packet because 212 of its header chain length. However, the forwarder MAY support a 213 configuration option that causes it to discard packets whose 214 header chain length exceeds a specified value. 216 o REQ-2: When processing packet that contains a hop-by-hop extension 217 header, an IPv6 forwarder MUST process the entire hop-by-hop 218 extension header, regardless of its length. The forwarder MUST 219 process each option as specified in Section 4.2 of [RFC2460]. 221 o REQ-3: When processing a packet whose destination address is local 222 to itself, an IPv6 forwarder MUST scan the entire header chain, 223 regardless of its length, in order to determine whether the packet 224 contains a routing extension header. If the packet contains a 225 routing extension header, the forwarder MUST process routing 226 extension header as specified in Section 4.4 of [RFC2460]. 228 The length of the IPv6 header plus the length of the hop-by-hop 229 extension header can exceed the number of bytes that an ASIC-based 230 forwarder copies into on-chip memory. Therefore, in order to support 231 REQ-2, ASIC-based forwarders typically support a special processing 232 mechanism for packets containing hop-by-hop extensions. 234 Also, the combined length of all headers preceding the routing 235 extension header may exceed the number of bytes that an ASIC-based 236 forwarder copies into on-chip memory. Therefore, in order to support 237 REQ-3, ASIC-based forwarders typically support a special processing 238 mechanism for packets whose IPv6 destination address is local to the 239 forwarder. This forwarding mechanism is capable of processing the 240 routing extension header, even if it begins beyond of the portion of 241 the packet that was copied to on-chip memory. 243 The following requirements apply to IPv6 forwarders that provide 244 enhanced forwarding services: 246 o REQ-4: If a forwarder's ability to deliver enhanced services is 247 limited in any way by extension header length, that limitation 248 MUST be reflected in user documentation. For example, assume that 249 a forwarder provides a load balancing service, and that it 250 acquires information required by the service from the IPv6 header 251 and the upper-layer header. If the service behaves in one manner 252 when all required information is contained by the first N bytes of 253 the header chain and in another manner when all required 254 information is not contained by the first N bytes of the header 255 chain, user documentation MUST reflect both behaviors as well as 256 the value of N. 258 o REQ-5: If a forwarder's ability to deliver an enhanced service is 259 limited by extension header length, the policy specification 260 language used to configure the enhanced service MUST be 261 sufficiently robust to address the limitation. For example, 262 assume that the forwarder provides a firewall service. The 263 firewall service is capable of filtering packets directed to a 264 particular TCP port, but only if the TCP header is contained by 265 the first N bytes of the header chain. In this case, it MUST be 266 possible to configure one policy for packets directed to the 267 specified port, another policy for packet not directed to the 268 specified port, and a third policy for packets whose TCP 269 destination port is unknown. 271 4. Recommendations For Application Developers 273 Applications developers should be aware that many ISPs and 274 enterprises filter or severely rate limit packets containing long 275 header chains. They do this because of limitations imposed by the 276 ASIC-based forwarders deployed at their edges. ISPs and enterprises 277 accept these limitations as part of an engineering trade off, in 278 which high-speed forwarding is achieved at the cost of limiting 279 enhanced services for packets with long extension headers. 281 For example, assume that an enterprise deploys the following firewall 282 filtering policy at its edge: 284 o Permit all packets whose destination is TCP port 80 286 o Discard all packets whose destination is not TCP port 80 288 o Discard all packets whose header chain is so long that TCP port 289 information is not accessible to the filtering function 291 In this case, the enterprise discards all packets whose destination 292 cannot be determined by the filtering function. 294 Aside from the issue of header chain length, operators may filter 295 packets containing extension headers that may either compromise the 296 network's security posture or require inordinate processing 297 resources. 299 This memo does not specify a maximum header chain length. However, 300 this memo does note that at the time of its publication, the number 301 of bytes that ASIC-based forwarders copy from the beginning of a 302 packet to on-chip memory varies from platform to platform. Typical 303 platforms copy between 128 and 384 bytes. Therefore, application 304 developers should avoid sending packets who header chain length is in 305 that range, unless they have some assurance that their packets will 306 not be discarded. 308 5. IANA Considerations 310 This document makes no requests of the IANA 312 6. Security Considerations 314 TBD 316 7. Acknowledgements 317 The authors wish to thank Paul Hoffman, KK and Fernando Gont. The 318 authors also express their gratitude to an anonymous donor, without 319 whom this document would not have been written. 321 8. References 323 8.1. Normative References 325 [I-D.ietf-6man-oversized-header-chain] 326 Gont, F., Manral, V., and R. Bonica, "Implications of 327 Oversized IPv6 Header Chains", draft-ietf-6man-oversized- 328 header-chain-08 (work in progress), October 2013. 330 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 331 Requirement Levels", BCP 14, RFC 2119, March 1997. 333 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 334 (IPv6) Specification", RFC 2460, December 1998. 336 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 337 "Definition of the Differentiated Services Field (DS 338 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 339 1998. 341 8.2. Informative References 343 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 344 in IPv6", RFC 6275, July 2011. 346 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 347 Routing Header for Source Routes with the Routing Protocol 348 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 349 2012. 351 Appendix A. Changes / Author Notes. 353 [RFC Editor: Please remove this section before publication ] 355 Template to -00 357 o Initial submission. 359 -00 to -01 361 o Added maximum header chain recommendation. 363 o Rewrite the forwarding description. 365 Authors' Addresses 367 Warren Kumari 368 Google 369 1600 Amphitheatre Parkway 370 Mountain View, CA 94043 371 US 373 Email: warren@kumari.net 375 Joel Jaeggli 376 Zynga 377 675 East Middlefield 378 Mountain View, CA 379 USA 381 Email: jjaeggli@zynga.com 383 Ronald P Bonica 384 Juniper Networks 385 2251 Corporate Park Drive 386 Herndon, VA 387 USA 389 Email: rbonica@juniper.net