idnits 2.17.1 draft-eastlake-6man-hide-options-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 (July 12, 2021) is 1016 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) == Outdated reference: A later version (-06) exists of draft-peng-v6ops-hbh-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. Eastlake 2 Intended status: Proposed Standard Futurewei Technologies 3 Expires: January 11, 2022 July 12, 2021 5 Transient Hiding of Hop-by-Hop Options 6 8 Abstract 9 There are increasing requests for a variety IPv6 hop-by-hop options 10 but such IPv6 options and all IPv4 options, are poorly handled, 11 particularly by high speed routers in the core Internet where packets 12 having options are commonly discarded. This document proposes a 13 simple method of transiently hiding such options for part of a 14 packet's path to protect the packet from discard. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Distribution of this document is unlimited. Comments should be sent 22 to the IPv6 Maintenance Working Group mailing list <6man@ietf.org> or 23 to the authors. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 https://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Conventions Used in This Document......................3 45 2. IP Options and Option Handling Problems.................4 47 2.1 IPv6 Options...........................................5 48 2.2 IPv4 Options...........................................6 50 3. Overview of a Solution..................................8 51 3.1 Transiently Hiding IPv6 Options........................9 52 3.2 Transiently Hiding IPv4 Options........................9 53 3.3 Evolution to Greater Option Support...................10 55 4. IANA Considerations....................................11 56 5. Security Considerations................................11 58 Normative References......................................12 59 Informative References....................................12 61 Authors' Address..........................................14 63 1. Introduction 65 As discussed in [Options3] there are increasing requests for a 66 variety IPv6 hop-by-hop options but such IPv6 options and all IPv4 67 options, are poorly handled, particularly by high speed routers in 68 the core Internet where packets having options are commonly 69 discarded. This document proposes a simple method of transiently 70 hiding such options for part of a packet's path to protect the packet 71 from discard. 73 1.1 Conventions Used in This Document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 77 "OPTIONAL" in this document are to be interpreted as described in BCP 78 14 [RFC2119] [RFC8174] when, and only when, they appear in all 79 capitals, as shown here. 81 Terms: 83 field - an area of one or more contiguous bits within a larger 84 structure. 86 2. IP Options and Option Handling Problems 88 This Section 2 is informational and intended to provide background 89 information. 91 In the early days of the Internet, much of the traffic was text, 92 transmission speeds were slow and IP routers were commonly small 93 general-purpose computers. Under these conditions, parsing IP headers 94 with various options or combinations of options, handling variable 95 length options, etc., was relatively easy. 97 However, as the Internet increased in size, bandwidth grew including 98 more voluminous media such as video, transmission speeds increased 99 enormously, and latency/responsiveness requirements became much more 100 stringent, IP routers, especially in the core of the Internet, 101 typically became less flexible and more specialized. To be able to 102 handle data faster and more efficiently, such core IP routers are 103 divided into a forwarding plane and a control plane where the 104 forwarding plan handles the usual data forwarding while the control 105 plan handles routing control messages and other packets that the data 106 plane cannot handle. In some IP routers, the forwarding plane is 107 implemented with Application Specific Integrated Circuits (ASICs) 108 that are inflexible and may need fields they examine in an IP packet 109 header and following fields to be at a fixed offset from the 110 beginning of the packet. Meanwhile, the control plane may be 111 implemented through a relatively low power general purpose computer 112 which can only handle a small number of packets per unit time. 114 For these reasons, many IP routers do not implement many or any types 115 of IPv6 Hop-by-Hop options or IPv4 header options except through the 116 control plane which is relatively slow. Sending packets with such 117 options to the control plane can overwhelm the control plane and 118 interfere with routing control messages or other critical functions. 119 Very often, particularly for IP routers handling a large amount of 120 traffic, a strategy is adopted of dropping IP packets with such 121 header options or ignoring IPv4 header options and IPv6 Hop-by-Hop 122 header options. 124 See [Options3] for a further discussion of these option handling 125 problems. 127 Further details concerning IPv6 and IPv4 options are given in the 128 subsections below. 130 2.1 IPv6 Options 132 Figure 1 shows the IPv6 header [RFC8200]. The value of the initial 133 4-bit Version field indicates the IP version number and has the value 134 6. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |Version| Traffic Class | Flow Label | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Payload Length | Next Header | Hop Limit | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | | 144 + + 145 | | 146 + Source Address + 147 | | 148 + + 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 + + 153 | | 154 + Destination Address + 155 | | 156 + + 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: IPv6 Header 162 The value of the 8-bit Next Header field specifies the type and 163 format of information immediately following the header. For example, 164 a value of 17 in the Next Header field indicates that the header is 165 immediately followed by a User Datagram Protocol (UDP) message and a 166 value of 6 would indicate the header is followed by a Transmission 167 Control Protocol (TCP) message. In some cases, the data immediately 168 after the IPv6 header can be a header including a Next Header field 169 for the type of data following it and so on as shown in Figure 2. 170 Such headers, after the initial IPv6 header and before the main 171 payload, are called Extension Headers and can be viewed as extensions 172 to the IPv6 header. At this time, specified extension headers include 173 the six listed below, additional extension headers have been 174 proposed, and likely more extension headers will be proposed and 175 specified in the future. 177 Specified extension headers: 178 Hop-by-Hop Options 179 Fragment 180 Destination Options 181 Routing 182 Authentication 183 Encapsulating Security Payload 185 In the two "options" types of extension header, the "Hop-by-Hop 186 Options" and "Destination Options", the extension header content is 187 further structured into options each of which, except for a one byte 188 "pad1" option, is an 8-bit type followed by an 8-bit option length, 189 followed by the option value. Hop-by-Hop options were initially 190 specified to require that every router pay attention to them. While 191 this has been relaxed in the most recent IPv6 specification, they are 192 still frequently viewed as imposing a burden on every IP router 193 through which they pass. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Next Header | Hdr Ext Len | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 200 | | 201 . . 202 . Options . 203 . . 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2: IPv6 Option Extension Header 209 2.2 IPv4 Options 211 Figure 3 shows the IPv4 header [RFC791]. The value of the initial 212 4-bit Version field indicates the IP version number and has value 4. 214 The IPv4 header has many similarities to the iPv6 header. For 215 example, the IPv4 header 8-bit field called "Protocol" is the like 216 the "Next Header" field in the IPv6 header and the IPv4 header 8-bit 217 "Type of Service" field, as amended by RFCs issued after [RFC791], is 218 the same as the IPv6 header "Traffic Class" field. But some things 219 that are handled by header extensions for IPv6 are integrated into 220 the more complex IPv4 header. For example, fragmentation, where an 221 Internet Protocol packet is split into pieces that can be later 222 combined because the packet might be too big to traverse part of its 223 path, is indicated through an extension header for IPv6 but through 224 fields in the main IPv4 header for IPv4. Similarly, IPv4 options are 225 considered part of the IPv4 header and the size of the options can be 226 determined from the value of the IHL (Internet Header Length) field 227 which gives the size of the IPv4 header in units of 4-octet words. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |Version| IHL |Type of Service| Total Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Identification |Flags| Fragment Offset | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Time to Live | Protocol | Header Checksum | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Source Address | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Destination Address | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Options | Padding | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: IPv4 Header 247 3. Overview of a Solution 249 Figure 4 shows a very high level view of a network path between two 250 hosts within local networks through the Internet core. (In reality 251 there will be more levels with a local network, whether a home, 252 office, data center, or whatever, is usually connected through one or 253 more levels of lower tier service provider before connecting to a 254 Tier 1 provider that connects to the default free Internet core.) 256 - - - - - - - - - - - - - - - - . . - - - - - - - - - - 257 . Network 1 . . Core Internet . 258 . . . . 259 . +------+ +---+ +---+ . . +---+ . 260 . |Host A|---|R10|-...-|R19|------------------|R90| . 261 . +------+ +---+ +---+ . . +---+ . 262 . . . | | . 263 . - - - - - - - - - - - - - - - - . ... 264 . ..... 265 . ....... 266 . ....... 267 - - - - - - - - - - - - - - - - . . ..... 268 . Network 2 . . ... 269 . . . | | . 270 . +------+ +---+ +---+ . . +---+ . 271 . |Host B|---|R20|-...-|R29|------------------|R99| . 272 . +------+ +---+ +---+ . . +---+ . 273 . . . . 274 . - - - - - - - - - - - - - - - - - - - - - - - - - - . 276 Figure 4: High Level View of an Internet Path 278 There are efforts to improve and streamline handling of IPv6 Hop-by- 279 Hop options such as in [Options1] and [Options2]. However, even if 280 popular and even if fully deployed in some network areas, there is 281 likely to be substantial delay before they are deployed in the 282 Internet core. While some Internet core routers may ignore options, 283 others discard all packets with options and, as long as there is a 284 significant chance of such discard, options are rendered essentially 285 useless on paths through the core. 287 The solution in this document is to hide options before IP packets 288 arrive at the core. This hiding is done in as easily detectable 289 fashion so that options can be unhidden after leaving the core. IPv6 290 Hop-by-Hop options or IPv4 options used with this solution may not be 291 effective in the core but the situation is an improvement over the 292 traffic using such options being discarded. This solution requires 293 destination support but that should be knowable in many cases such as 294 traffic between branches of the same company or between a customer 295 and a data center. 297 To obtain more uniform handling of packets in a flow, it may be 298 desireable to treat all packet in the flow, or all packets including 299 and after the first with problematic options, as if they had such 300 options in that the packet would be transformed to hide and unhide 301 options even if there were none. 303 3.1 Transiently Hiding IPv6 Options 305 IPv6 Hop-by-Hop options are hidden by replacing the zero Next Header 306 field in the IPv6 Header by the opaque IP protocol number TBD. This 307 is a very simple modification of one 8-bit field in a fixed location 308 that has no effect of the size of the packet. They are unhidden by 309 changing the opaque IP protocol number in the IPv6 header back to 310 zero. 312 The use of the opaque IP protocol number can defeat deeper IPv6 313 packet analysis that is intended to identify flows. It is therefore 314 RECOMMENDED that, when this hiding technique is used, the IPv6 header 315 Flow Label field be set [RFC6437] and used [RFC6438] [RFC7098]. This 316 is a good idea anyway since IPv6 extension headers may move some 317 fields, such as port numbers, on which flow identity might be based, 318 so deep into a packet that they are hard to use by routers. 320 3.2 Transiently Hiding IPv4 Options 322 A similar technique can be used for hiding IPv4 options but 323 significantly more complex manipulations of the packet are required. 324 As shown in Figure 5, the IPv4 header is made to appear to have no 325 options by setting the IHL (Internet Header Length) field to its 326 minimum value of 5, the Protocol field is changed to the opaque IP 327 protocol number TBD, and the Header Checksum is adjusted to be 328 correct for the optionless header. To be able to restore the IPv4 329 header, the old IHL, Protocol, and Header Checksum fields are saved 330 in a 4-octet word inserted after the Destination Address and before 331 any Options. The placement of the saved fields is such that their 332 alignment within 4-octet word is the same as in the unmodified IPv4 333 header. The field labeled MBZ MUST be sent as zero and ignored on 334 receipt. 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 |Version| IHL=5 |Type of Service| Total Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Identification |Flags| Fragment Offset | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Time to Live |Protocol=Opaque| Adjusted Header Checksum | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Source Address | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Destination Address | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | MBZ |SavdIHL| Saved Protocol| Saved Header Checksum | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Options | Padding | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 5: Modified IPv4 Header 356 These modifications increase the size of the IPv4 packet, increasing 357 the chance that fragmentation or MTU problems could occur. For any 358 node ignorant of the opaque IP protocol number, they will also 359 interfere with flow determination based on the traditional 5-tuple 360 (source and destination address, source and destination port, and IP 361 protocol) or deep packet inspection. 363 3.3 Evolution to Greater Option Support 365 This solution supports the evolution of the Internet toward more 366 widespread support of options including the following: 368 o As acceptable option support is more widely implemented, probably 369 starting at lower bandwidth routers nearer the edge, the 370 boundaries at which options are hidden or unhidden can migrate 371 closer to the core. 373 o If scattered core routers improve to provide acceptable option 374 support, they can recognize the opaque protocol number and perform 375 options, perhaps in a limited way, on packets where those options 376 are hidden to unimproved routers. 378 4. IANA Considerations 380 IANA is request to assign a number from the "Assigned Internet 381 Protocol Numbers" registry as follows: 383 Decimal Keyword Protocol IPv6 Ex Hdr Reference 384 ------- ------- -------- ----------- --------- 385 TBD Opaque Opaque [this document] 387 5. Security Considerations 389 The use of the opaque IP Protocol to mask options is intended to 390 defeat analysis of the following packet content. This would make 391 firewalls, deep packet analysis, and the like less effective. 393 Normative References 395 [RFC791] - Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 396 10.17487/RFC0791, September 1981, https://www.rfc- 397 editor.org/info/rfc791 399 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 401 March 1997, . 403 [RFC6437] - Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 404 "IPv6 Flow Label Specification", RFC 6437, DOI 405 10.17487/RFC6437, November 2011, 406 . 408 [RFC6438] - Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 409 for Equal Cost Multipath Routing and Link Aggregation in 410 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 411 . 413 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 414 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 415 2017, 417 [RFC8200] - Deering, S. and R. Hinden, "Internet Protocol, Version 6 418 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, 419 July 2017, https://www.rfc-editor.org/info/rfc8200 421 Informative References 423 [Options1] - Li, Z., Peng, S., and G. Mishra, "Hop-by-Hop Forwarding 424 Options Header", Internet draft-li-6man-hbh-fwd-hdr-01, 425 February 2021, 426 https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/ 428 [Options2] - Hinden, R., and G. Fairhurst, "IPv6 Hop-by-Hop options 429 Processing Procedures", Internet draft-hinden-6man-hbh- 430 processing-01, June 2021, 431 https://datatracker.ietf.org/doc/draft-hinden-6man-hbh- 432 processing/ 434 [Options3] - Peng, S., Li, Z., Xie, C., and Z. Qin, "Processing of 435 the Hop-by-Hop Options Header", Internet draft-peng-v6ops- 436 hbh-04, June 2021, 437 https://datatracker.ietf.org/doc/draft-peng-v6ops-hbh/ 439 [RFC7098] - Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 440 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 441 10.17487/RFC7098, January 2014, 442 . 444 Authors' Address 446 Donald E. Eastlake 3rd 447 Futurewei Technologies 448 2386 Panoramic Circle 449 Apopka, FL 32703 USA 451 Tel: +1-508-333-2270 452 Email: d3e3e3@gmail.com 454 Copyright and IPR Provisions 456 Copyright (c) 2021 IETF Trust and the persons identified as the 457 document authors. All rights reserved. 459 This document is subject to BCP 78 and the IETF Trust's Legal 460 Provisions Relating to IETF Documents 461 (http://trustee.ietf.org/license-info) in effect on the date of 462 publication of this document. Please review these documents 463 carefully, as they describe your rights and restrictions with respect 464 to this document. Code Components extracted from this document must 465 include Simplified BSD License text as described in Section 4.e of 466 the Trust Legal Provisions and are provided without warranty as 467 described in the Simplified BSD License. The definitive version of 468 an IETF Document is that published by, or under the auspices of, the 469 IETF. Versions of IETF Documents that are published by third parties, 470 including those that are translated into other languages, should not 471 be considered to be definitive versions of IETF Documents. The 472 definitive version of these Legal Provisions is that published by, or 473 under the auspices of, the IETF. Versions of these Legal Provisions 474 that are published by third parties, including those that are 475 translated into other languages, should not be considered to be 476 definitive versions of these Legal Provisions. For the avoidance of 477 doubt, each Contributor to the IETF Standards Process licenses each 478 Contribution that he or she makes as part of the IETF Standards 479 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 480 language to the contrary, or terms, conditions or rights that differ 481 from or are inconsistent with the rights and licenses granted under 482 RFC 5378, shall have any effect and shall be null and void, whether 483 published or posted by such Contributor, or included with or in such 484 Contribution.