idnits 2.17.1 draft-eastlake-6man-hide-options-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 (April 11, 2022) is 743 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 (-10) exists of draft-ietf-v6ops-hbh-00 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: October 10, 2022 April 11, 2022 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 are poorly handled, particularly by high-speed 11 routers in the core Internet where packets having options are 12 commonly discarded. This document proposes a simple method of 13 transiently hiding such options for part of a packet's path to 14 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 46 2.1 IPv6 Options...........................................4 48 3. Overview of a Solution..................................7 49 3.1 Transiently Hiding IPv6 Options........................8 50 3.2 Evolution to Greater Option Support....................8 52 4. IANA Considerations....................................10 53 5. Security Considerations................................10 54 6. Acknowledgements.......................................10 56 Normative References......................................11 57 Informative References....................................11 59 Authors' Address..........................................12 61 Appendix: Revision History................................13 62 -00 to -01................................................13 63 -01 to -02................................................13 65 1. Introduction 67 As discussed in [Options3] there are increasing requests for a 68 variety IPv6 hop-by-hop options but such IPv6 options, are poorly 69 handled, particularly by high-speed routers in the core Internet 70 where packets having options are commonly discarded. This document 71 proposes a simple method of transiently hiding such options for part 72 of a packet's path to protect the packet from discard. 74 1.1 Conventions Used in This Document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in BCP 79 14 [RFC2119] [RFC8174] when, and only when, they appear in all 80 capitals, as shown here. 82 Terms: 84 ASIC - Application Specific Integrated Circuit. 86 field - an area of one or more contiguous bits within a larger 87 structure. 89 2. IP Options and Option Handling Problems 91 This Section 2 is informational and intended to provide background 92 information. 94 In the early days of the Internet, much of the traffic was text, 95 transmission speeds were slow, and IP routers were commonly small 96 general-purpose computers. Under these conditions, parsing IP headers 97 with various options or combinations of options, handling variable 98 length options, etc., was relatively easy. 100 However, as the Internet increased in size bandwidth grew including 101 more voluminous media such as video, transmission speeds increased 102 enormously, and latency/responsiveness requirements became much more 103 stringent. This leads to IP routers, especially in the core of the 104 Internet, becoming less flexible and more specialized. To be able to 105 handle data faster and more efficiently, such core IP routers are 106 divided into a forwarding plane and a control plane where the 107 forwarding plan handles the usual data forwarding while the control 108 plan handles routing control messages and other packets that the data 109 plane cannot handle. In some IP routers, the forwarding plane is 110 implemented with Application Specific Integrated Circuits (ASICs) 111 that are inflexible and may need fields they examine in an IP packet 112 header to be at a fixed offset from the beginning of the packet. 113 Meanwhile, the control plane may be implemented through a general 114 purpose computer which can only handle a limited number of packets 115 per unit time. 117 For these reasons, many IP routers do not implement many or any types 118 of IPv6 Hop-by-Hop options (or IPv4 header options) except through 119 the control plane which has limited capacity. Sending packets with 120 such options to the control plane can overwhelm the control plane and 121 interfere with routing control messages or other critical functions. 122 Very often, particularly for IP routers handling a large volume of 123 traffic, a strategy is adopted of dropping IP packets with such 124 header options or ignoring the header options. 126 See [Options3] for a further discussion of these option handling 127 problems. 129 2.1 IPv6 Options 131 Figure 1 shows the IPv6 header [RFC8200]. The value of the initial 132 4-bit Version field indicates the IP version number and has the value 133 6. 135 0 1 2 3 136 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 that itself includes a Next 169 Header field for the type of data following it and so on as shown in 170 Figure 2. Such headers, after the initial IPv6 header and before the 171 main payload, are called Extension Headers and can be viewed as 172 extensions to the IPv6 header. At this time, specified extension 173 headers include the six listed below, additional extension headers 174 have been proposed, and likely more extension headers will be 175 proposed and 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 3. Overview of a Solution 211 Figure 3 shows a very high-level view of a network path between two 212 hosts within local networks through the Internet core. (In reality 213 there will be more levels with a local network, whether a home, 214 office, data center, or whatever, usually connected through one or 215 more levels of lower tier service provider before connecting to a 216 Tier 1 provider that connects to the Internet core also known as the 217 defalt free zone.) 219 - - - - - - - - - - - - - - - - . . - - - - - - - - - - 220 . Network 1 . . Core Internet . 221 . . . . 222 . +------+ +---+ +---+ . . +---+ . 223 . |Host A|---|R10|-...-|R19|------------------|R90| . 224 . +------+ +---+ +---+ . . +---+ . 225 . . . | | . 226 . - - - - - - - - - - - - - - - - . ... 227 . ..... 228 . ....... 229 . ....... 230 - - - - - - - - - - - - - - - - . . ..... 231 . Network 2 . . ... 232 . . . | | . 233 . +------+ +---+ +---+ . . +---+ . 234 . |Host B|---|R20|-...-|R29|------------------|R99| . 235 . +------+ +---+ +---+ . . +---+ . 236 . . . . 237 . - - - - - - - - - - - - - - - - - - - - - - - - - - . 239 Figure 3: High Level View of an Internet Path 241 There are efforts to improve and streamline handling of IPv6 Hop-by- 242 Hop options such as the methods in [Options1] and [Options2]. 243 However, even if such a method were popular and fully deployed in 244 some network areas, there is likely to be substantial delay before it 245 would be deployed in most of the Internet core. While some Internet 246 core routers may ignore options, others discard all packets with 247 options and, as long as there is a significant chance of such 248 discard, options are rendered essentially useless on paths through 249 the core. 251 A solution is to hide options before IP packets arrive at the core. 252 This hiding is done in an easily detectable and reversible fashion so 253 that options can be unhidden after leaving the core. IPv6 Hop-by-Hop 254 options so hidden might not be effective in the core but the 255 situation is an improvement over the traffic using such options being 256 discarded. 258 This solution requires destination support but that should be 259 knowable in many cases such as traffic between branches of the same 260 company or between a customer and a data center. 262 To obtain more uniform handling of packets in a flow, it may be 263 desireable to treat all packet in the flow as if they had such 264 options in that the packet would be transformed to hide and unhide 265 options even if there were none. This transformation could also be 266 applied to all packets starting with the first having a problematic 267 option. 269 3.1 Transiently Hiding IPv6 Options 271 IPv6 Hop-by-Hop options are hidden by replacing the zero Next Header 272 field in the IPv6 Header by the opaque IP protocol number TBD. This 273 is a very simple modification of one 8-bit field in a fixed location 274 that has no effect of the size of the packet. They are unhidden by 275 changing this opaque IP protocol number in the IPv6 header back to 276 zero. The points of hiding and unhiding in the packet's path (or 277 paths if multicast) should be chosen to maximize the routers at the 278 beginning and end of the path (Figure 3) that implement the options 279 seeing the options while minimizing he chance of unwanted packet 280 discard. 282 The use of the opaque IP protocol number can defeat deeper IPv6 283 packet analysis that is intended to identify flows. It is therefore 284 RECOMMENDED that, when this hiding technique is used, the IPv6 header 285 Flow Label field be set [RFC6437] and used to identify flows 286 [RFC6438] [RFC7098]. Using the Flow Label is a good idea anyway since 287 IPv6 extension headers can move some fields on which flow identity 288 might be based, such as port numbers, deeper into a packet so that 289 they are harder to use by routers. 291 3.2 Evolution to Greater Option Support 293 This solution supports the evolution of the Internet toward more 294 widespread support of options as follows: 296 o As acceptable option support is more widely implemented, probably 297 starting at lower bandwidth routers nearer the edge, the 298 boundaries at which options are hidden and unhidden can migrate 299 closer to the core. 301 o If scattered core routers improve to provide acceptable option 302 support, they can recognize the opaque protocol number and perform 303 options, perhaps in a limited way, on packets where those options 304 are hidden to unimproved routers. 306 4. IANA Considerations 308 IANA is request to assign a number from the "Assigned Internet 309 Protocol Numbers" registry as follows: 311 Decimal Keyword Protocol IPv6 Ex Hdr Reference 312 ------- -------- -------- ----------- -------------- 313 TBD Opaque Opaque [this document] 315 5. Security Considerations 317 The use of the opaque IP Protocol to mask options is intended to 318 defeat normal analysis of the following packet content, specifically 319 options in the IP header. This would make firewalls, deep packet 320 analysis, and the like less effective. On the other hand, firewalls 321 tend to only admit packets with known permissable values in protocol 322 header fields such as the IP protocol field. The rejection by a 323 firewall of a packet with the opaque IP protocol value will protect 324 the nodes behind that firewall from possible damage due to the 325 receipt of a packet modified as specified in this document. If the 326 firewall does know the opaque IP Protocol value, it should be 327 configured to treat packets with that value safely, possibly by 328 reversing the option hiding transformation. 330 Should an IPv6 packet modified to hide options get through to a host 331 that does not understand this modification, it would almost certainly 332 be discarded due to having an unknown IP Protocol. 334 [More to be added] 336 6. Acknowledgements 338 The helpful comments of the following are gratefully acknowledged: 340 Peng Shuping 342 Normative References 344 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 346 March 1997, . 348 [RFC6437] - Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 349 "IPv6 Flow Label Specification", RFC 6437, DOI 350 10.17487/RFC6437, November 2011, 351 . 353 [RFC6438] - Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 354 for Equal Cost Multipath Routing and Link Aggregation in 355 Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, 356 . 358 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 359 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 360 2017, 362 [RFC8200] - Deering, S. and R. Hinden, "Internet Protocol, Version 6 363 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, 364 July 2017, https://www.rfc-editor.org/info/rfc8200 366 Informative References 368 [Options1] - Li, Z., Peng, S., and G. Mishra, "Hop-by-Hop Forwarding 369 Options Header", Internet draft-li-6man-hbh-fwd-hdr-01, 370 February 2021, 371 https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/ 373 [Options2] - Hinden, R., and G. Fairhurst, "IPv6 Hop-by-Hop options 374 Processing Procedures", Internet draft-hinden-6man-hbh- 375 processing-01, June 2021, 376 https://datatracker.ietf.org/doc/draft-hinden-6man-hbh- 377 processing/ 379 [Options3] - Peng, S., Li, Z., Xie, C., and Z. Qin, "Operational 380 Issues with Processig of the Hop-by-Hop Options Header", 381 Internet draft-ietf-v6ops-hbh-00, June 2021, 382 https://datatracker.ietf.org/doc/draft-ietf-v6ops-hbh/ 384 [RFC7098] - Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 385 Flow Label for Load Balancing in Server Farms", RFC 7098, DOI 386 10.17487/RFC7098, January 2014, 387 . 389 Authors' Address 391 Donald E. Eastlake 3rd 392 Futurewei Technologies, Inc. 393 2386 Panoramic Circle 394 Apopka, FL 32703 USA 396 Tel: +1-508-333-2270 397 Email: d3e3e3@gmail.com 399 Appendix: Revision History 401 RFC Editor: Please delete this appendix before publication. 403 -00 to -01 405 Minor editorial changes. Add more Security Considerations. Add 406 Acknowledgements section. 408 -01 to -02 410 Delete IPv4 material. It was a bit complex and no one really cares 411 about IPv4 options. Also minor editorial changes. 413 Copyright and IPR Provisions 415 Copyright (c) 2022 IETF Trust and the persons identified as the 416 document authors. All rights reserved. 418 This document is subject to BCP 78 and the IETF Trust's Legal 419 Provisions Relating to IETF Documents 420 (http://trustee.ietf.org/license-info) in effect on the date of 421 publication of this document. Please review these documents 422 carefully, as they describe your rights and restrictions with respect 423 to this document. Code Components extracted from this document must 424 include Revised BSD License text as described in Section 4.e of the 425 Trust Legal Provisions and are provided without warranty as described 426 in the Revised BSD License.