idnits 2.17.00 (12 Aug 2021) /tmp/idnits28010/draft-wkumari-long-headers-03.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 (June 15, 2015) is 2525 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 350, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 2 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: December 17, 2015 Zynga 6 R. Bonica 7 Juniper Networks 8 J. Linkova 9 Google 10 June 15, 2015 12 Operational Issues Associated With Long IPv6 Header Chains 13 draft-wkumari-long-headers-03 15 Abstract 17 This memo specifies requirements for IPv6 forwarders as they process 18 packets with long header chains. It also provides guidance for 19 application developers whose applications might rely on long headers 20 chains. 22 As background, this memo explains how many ASIC-based IPv6 forwarders 23 process packets and why processing of packets with long header chains 24 might be problematic. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 17, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Termnology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Forwarder Information Requirements . . . . . . . . . . . . . 4 69 3. Requirements For IPv6 Forwarders . . . . . . . . . . . . . . 5 70 4. Recommendations For Application Developers . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 IPv6 [RFC2460] forwarders can acquire information from the following 83 sources: 85 o The IPv6 header 87 o One or more IPv6 extension headers 89 o An upper-layer header 91 Section 2 of this document explains how IPv6 forwarders use 92 information from the IPv6 header and IPv6 extension headers to 93 provide traditional forwarding services. It also explains how IPv6 94 forwarders use information from the upper-layer header to provide 95 enhanced forwarding services. 97 When a software-based forwarder processes an IPv6 datagram, it parses 98 the header chain, regardless of its length, acquires the required 99 information and makes a forwarding decision. Typically, software- 100 based forwarders process a relatively small number of packets per 101 second. Therefore, they can perform the above mentioned procedure 102 within the constraints of their processing budget. 104 By contrast, ASIC-based forwarders process many more packets per 105 second. In order to fulfill this requirement, ASIC-based forwarders 106 copy a fixed number of bytes from the beginning of the packet to on- 107 chip memory. Forwarders do this because they can access on-chip 108 memory much more quickly than they can access off-chip memory. Once 109 the beginning of the packet has been transferred to on-chip memory, 110 subsequent processing can proceed very quickly. 112 The act of copying bytes from the beginning of a packet to on-chip 113 memory consumes: 115 o Processor cycles 117 o On-chip memory 119 o Wall-time 121 Therefore, the number of bytes copied to on-chip memory must be 122 chosen wisely. If a forwarder copies more bytes than it needs, it 123 wastes resources and adversely impacts performance. If it copies too 124 few bytes, it may not have sufficient information to make a correct 125 forwarding decision. 127 The IPv6 header chain is a variable-length data structure, whose size 128 can exceed 64 kilobytes. However, packets with header chains 129 exceeding 256 bytes are rarely observed on the Internet. Therefore, 130 most ASIC-based forwarders copy a relatively small number of bytes 131 from the beginning of a packet into on-chip memory. While this small 132 number varies from platform to platform, it is generally much closer 133 to 256 bytes than it is to 64 kilobytes. 135 IPv6 forwarders MUST behave in a predictable manner when they process 136 a packet whose header chain length exceeds the number of bytes copied 137 to on-chip memory. Section 3 of this memo defines required 138 behaviors. 140 Application developers should be aware of how ASIC-based forwarders 141 process packets with long extension header chains. Therefore, 142 Section 4 of this document provides guidance to application 143 developers. 145 1.1. Termnology 147 For the purposes of this document, the terms "header chain" and 148 "upper-layer" header are used as defined in [RFC7112]. 150 This document also introduces the following terms: 152 o forwarding service - a service that accepts a packet from one 153 interface and forwards it through another 155 o traditional forwarding service - a forwarding service in which all 156 parameters to the forwarding algorithm are drawn from the IPv6 157 header, the hop-by-hop extension header, and the routing extension 158 header 160 o enhanced forwarding service - a forwarding service in which 161 parameters to the forwarding algorithm can be drawn from any 162 portion of the IPv6 header chain 164 2. Forwarder Information Requirements 166 When an IPv6 forwarder provides traditional forwarding services, it 167 extracts all information required by the forwarding algorithm from 168 the IPv6 header, the hop-by-hop extension header (if present), and 169 the routing extension header (if present). In the nominal case, the 170 IPv6 header contains all information required by the forwarding 171 algorithm. However, the hop-by-hop and routing extension headers can 172 also impact forwarding behavior. 174 Section 4.2 of [RFC2460] explains how the hop-by-hop extension header 175 impacts forwarding behavior. When the forwarder processes a hop-by- 176 hop extension header, it examines each option contained by the 177 header. If forwarder encounters an unrecognized hop-by-hop option, 178 and the high-order bits of the option type are "00", the forwarder 179 skips over the option and continues to process subsequent options. 180 However, if an forwarder encounters an unrecognized option, and the 181 high-order bits of the option type are "01", "10" or "11", the 182 forwarder discards the packet. 184 Section 4.4 of [RFC2460] explains how the routing extension header 185 impacts forwarding behavior. When the forwarder processes a packet 186 whose destination address is local to itself, it scans the header 187 chain, searching for a routing extension header. If the packet 188 contains a routing extension header and the forwarder recognizes the 189 routing header type, it processes the header. If the forwarder does 190 not recognize the routing header type, the required behavior depends 191 upon the Segments Left field. If the Segments Left field is equal to 192 zero, the forwarder ignores the routing extension header. Otherwise, 193 the forwarder discards the packet. [RFC6275] and [RFC6554] describe 194 currently defined routing extension header types. 196 Some IPv6 forwarders provide enhanced forwarding services, such as 197 firewall filtering, rate limiting and load balancing. In order to 198 provide these services, the forwarder requires access to an upper 199 layer header. The following are examples of enhanced services that 200 require the forwarder to examine the upper layer header: 202 o Discard all packets directed to TCP port 25 204 o Rate limit packets destined for a particular address whose payload 205 is TCP and have the TCP SYN bit set 207 o Load balance packets across parallel links so that all packet 208 belonging to particular TCP session traverse the same link. 210 3. Requirements For IPv6 Forwarders 212 The following requirements apply to all IPv6 forwarders: 214 o REQ-1: By default an IPv6 forwarder SHOULD NOT discard a valid 215 packet because of its header chain length. However, the forwarder 216 MAY support a configuration option that causes it to discard 217 packets whose header chain length exceeds a specified value. 219 o REQ-2: When processing packet that contains a hop-by-hop extension 220 header, an IPv6 forwarder MUST process the entire hop-by-hop 221 extension header, regardless of its length. The forwarder MUST 222 process each option as specified in Section 4.2 of [RFC2460]. If 223 an IPv6 forwarder is not able to process the entire hop-by-hop 224 extension header, it MUST discard the packet and SHOULD originate 225 an ICMPv6 Parameter Problem message to the packet's source. The 226 forwarder MAY have a configurable policy for sending ICMPv6 227 messages such as rate limiting or completely disabling them If an 228 IPv6 forwarder is not able to process the entire hop-by-hop 229 extension header, it MUST discard the packet and SHOULD originate 230 an ICMPv6 Parameter Problem message to the packet's source. The 231 forwarder MAY have a configurable policy for sending ICMPv6 232 messages such as rate limiting or completely disabling them. 234 o REQ-3: When processing a packet whose destination address is local 235 to itself, an IPv6 forwarder MUST scan the entire header chain, 236 regardless of its length, in order to determine whether the packet 237 contains a routing extension header. If the packet contains a 238 routing extension header, the forwarder MUST process routing 239 extension header as specified in Section 4.4 of [RFC2460]. If an 240 IPv6 forwarder is not able to process the entire routing extension 241 header, it MUST discard the packet and SHOULD originate an ICMPv6 242 Parameter Problem message to the packet's source. The forwarder 243 MAY have a configurable policy for sending ICMPv6 messages such as 244 rate limiting or completely disabling them. 246 The length of the IPv6 header plus the length of the hop-by-hop 247 extension header can exceed the number of bytes that an ASIC-based 248 forwarder copies into on-chip memory. Therefore, in order to support 249 REQ-2, ASIC-based forwarders typically support a special processing 250 mechanism for packets containing hop-by-hop extensions. 252 Also, the combined length of all headers preceding the routing 253 extension header may exceed the number of bytes that an ASIC-based 254 forwarder copies into on-chip memory. Therefore, in order to support 255 REQ-3, ASIC-based forwarders typically support a special processing 256 mechanism for packets whose IPv6 destination address is local to the 257 forwarder. This forwarding mechanism is capable of processing the 258 routing extension header, even if it begins beyond of the portion of 259 the packet that was copied to on-chip memory. 261 The following requirements apply to IPv6 forwarders that provide 262 enhanced forwarding services: 264 o REQ-4: If a forwarder's ability to deliver enhanced services is 265 limited in any way by extension header length, that limitation 266 MUST be reflected in user documentation. For example, assume that 267 a forwarder provides a load balancing service, and that it 268 acquires information required by the service from the IPv6 header 269 and the upper-layer header. If the service behaves in one manner 270 when all required information is contained by the first N bytes of 271 the header chain and in another manner when all required 272 information is not contained by the first N bytes of the header 273 chain, user documentation MUST reflect both behaviors as well as 274 the value of N. 276 o REQ-5: If a forwarder's ability to deliver an enhanced service is 277 limited by extension header length, the policy specification 278 language used to configure the enhanced service MUST be 279 sufficiently robust to address the limitation. For example, 280 assume that the forwarder provides a firewall service. The 281 firewall service is capable of filtering packets directed to a 282 particular TCP port, but only if the TCP header is contained by 283 the first N bytes of the header chain. In this case, it MUST be 284 possible to configure one policy for packets directed to the 285 specified port, another policy for packet not directed to the 286 specified port, and a third policy for packets whose TCP 287 destination port is unknown. 289 4. Recommendations For Application Developers 291 Applications developers should be aware that many ISPs and 292 enterprises filter or severely rate limit packets containing long 293 header chains. They do this because of limitations imposed by the 294 ASIC-based forwarders deployed at their edges. ISPs and enterprises 295 accept these limitations as part of an engineering trade off, in 296 which high-speed forwarding is achieved at the cost of limiting 297 enhanced services for packets with long extension headers. 299 For example, assume that an enterprise deploys the following firewall 300 filtering policy at its edge: 302 o Permit all packets whose destination is TCP port 80 304 o Discard all packets whose destination is not TCP port 80 306 o Discard all packets whose header chain is so long that TCP port 307 information is not accessible to the filtering function 309 In this case, the enterprise discards all packets whose destination 310 cannot be determined by the filtering function. 312 Aside from the issue of header chain length, operators may filter 313 packets containing extension headers that may either compromise the 314 network's security posture or require inordinate processing 315 resources. 317 This memo does not specify a maximum header chain length. However, 318 this memo does note that at the time of its publication, the number 319 of bytes that ASIC-based forwarders copy from the beginning of a 320 packet to on-chip memory varies from platform to platform. Typical 321 platforms copy between 128 and 384 bytes. Therefore, application 322 developers should avoid sending packets who header chain length is in 323 that range, unless they have some assurance that their packets will 324 not be discarded. 326 5. IANA Considerations 328 This document makes no requests of the IANA 330 6. Security Considerations 332 TBD 334 7. Acknowledgements 336 The authors wish to thank Paul Hoffman, KK and Fernando Gont. The 337 authors also express their gratitude to an anonymous donor, without 338 whom this document would not have been written. 340 8. References 342 8.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 348 (IPv6) Specification", RFC 2460, December 1998. 350 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 351 "Definition of the Differentiated Services Field (DS 352 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 353 1998. 355 [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of 356 Oversized IPv6 Header Chains", RFC 7112, January 2014. 358 8.2. Informative References 360 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 361 in IPv6", RFC 6275, July 2011. 363 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 364 Routing Header for Source Routes with the Routing Protocol 365 for Low-Power and Lossy Networks (RPL)", RFC 6554, March 366 2012. 368 Appendix A. Changes / Author Notes. 370 [RFC Editor: Please remove this section before publication ] 372 Template to -00 374 o Initial submission. 376 o 378 -00 to -01 380 o Added maximum header chain recommendation. 382 o Rewrite the forwarding description. 384 -02 to -03 386 o Updating REQ2 and REQ3 with sending ICMPv6 messages part. 388 Authors' Addresses 390 Warren Kumari 391 Google 392 1600 Amphitheatre Parkway 393 Mountain View, CA 94043 394 US 396 Email: warren@kumari.net 398 Joel Jaeggli 399 Zynga 400 675 East Middlefield 401 Mountain View, CA 402 USA 404 Email: jjaeggli@zynga.com 406 Ronald P Bonica 407 Juniper Networks 408 2251 Corporate Park Drive 409 Herndon, VA 410 USA 412 Email: rbonica@juniper.net 414 J. Linkova 415 Google 416 1600 Amphitheatre Parkway 417 Mountain View, CA 94043 418 USA 420 Email: furry@google.com