idnits 2.17.1 draft-smith-6man-in-flight-eh-insertion-harmful-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2020) is 1420 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) == Missing Reference: 'RFC4271' is mentioned on line 148, but not defined == Missing Reference: 'RFC1122' is mentioned on line 461, but not defined == Missing Reference: 'RFC6272' is mentioned on line 461, but not defined == Missing Reference: 'RFC3031' is mentioned on line 516, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft 4 Intended status: Best Current Practice N. Kottapalli 5 Expires: December 1, 2020 6 R. Bonica 7 Juniper Networks 8 F. Gont 9 SI6 Networks 10 T. Herbert 11 Quantonium 12 May 30, 2020 14 In-Flight IPv6 Extension Header Insertion Considered Harmful 15 draft-smith-6man-in-flight-eh-insertion-harmful-02 17 Abstract 19 In the past few years, as well as currently, there have and are a 20 number of proposals to insert IPv6 Extension Headers into existing 21 IPv6 packets while in-flight. This contradicts explicit prohibition 22 of this type of IPv6 packet proccessing in the IPv6 standard. This 23 memo describes the possible failures that can occur with EH 24 insertion, the harm they can cause, and the existing model that is 25 and should continue to be used to add new information to an existing 26 IPv6 and other packets. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 1, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. In-Flight Extension Header Insertion Defined . . . . . . . . 3 66 3.1. In-Flight Insertion . . . . . . . . . . . . . . . . . . . 3 67 3.2. In-Flight Removal . . . . . . . . . . . . . . . . . . . . 4 68 3.3. In-Flight Insertion Without Removal . . . . . . . . . . . 4 69 4. EH Removal Failure Causes . . . . . . . . . . . . . . . . . . 4 70 4.1. Implementation Bugs . . . . . . . . . . . . . . . . . . . 4 71 4.2. Partial Node Failure . . . . . . . . . . . . . . . . . . 5 72 4.3. Operator Configuration Error . . . . . . . . . . . . . . 5 73 5. Single Point of Failure . . . . . . . . . . . . . . . . . . . 5 74 6. MUST Remove is Aspirational . . . . . . . . . . . . . . . . . 6 75 7. Harm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Violates RFC8200 and All Of Its Ancestors. . . . . . . . 6 77 7.2. Ignores Source Address Field Semantics . . . . . . . . . 6 78 7.3. Breaks ICMPv6 . . . . . . . . . . . . . . . . . . . . . . 6 79 7.3.1. Breaks PMTUD . . . . . . . . . . . . . . . . . . . . 6 80 7.4. Breaks IPsec . . . . . . . . . . . . . . . . . . . . . . 6 81 7.5. May Cause Faults in Subsequent Transit Networks . . . . . 6 82 7.6. Incorrect Destination Host Processing . . . . . . . . . . 6 83 7.7. Implementation Complexity . . . . . . . . . . . . . . . . 7 84 7.8. Costly Troubleshooting . . . . . . . . . . . . . . . . . 8 85 8. Be conservative in what you send, ... . . . . . . . . . . . . 10 86 9. Solution: Encapsulation . . . . . . . . . . . . . . . . . . . 10 87 9.1. IPv6 Tunnelling . . . . . . . . . . . . . . . . . . . . . 11 88 9.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 10. Reducing Tunneling Overhead . . . . . . . . . . . . . . . . . 12 90 10.1. ROHC . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 10.2. Skinny IPv6-in-IPv6 Tunneling . . . . . . . . . . . . . 12 92 11. In-Flight Insertion Considered Harmful . . . . . . . . . . . 13 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 95 14. Change Log [RFC Editor please remove] . . . . . . . . . . . . 13 96 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 98 15.2. Informative References . . . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Introduction 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Terminology 111 o In-Flight - the state of a packet while it is travelling throught 112 the network between its original source IPv6 and final destination 113 IPv6 hosts. The packet will be being forwarded along a series of 114 hops along a set of IPv6 routers interconnecting the source and 115 destination IPv6 hosts. 117 3. In-Flight Extension Header Insertion Defined 119 3.1. In-Flight Insertion 121 At a point somewhere along the path an IPv6 [RFC8200] packet travels 122 between the packet's source IPv6 host, identified in the packet's 123 Source Address field, and the packet's final IPv6 destination host, 124 identified in the packet's Destination Address field, the packet is 125 split apart after the IPv6 fixed header and before the packet 126 payload. Then, one or more new Extension Headers (EHs) [RFC8200] are 127 inserted between those two existing packet parts. The new EH or EHs 128 may be the sole EH or EHs in the packet after insertion, or it, or 129 they, may be inserted at the start, within, or after the packet's set 130 of original EHs. 132 Importantly, note that the packet's original source and Destination 133 Address field values are left unchanged when EH insertion takes 134 place. It is likely that other immutable fields of the IPv6 header 135 are also left unchanged, with possible exception to the immutable 136 Next Header field [RFC8200] if the inserted EH or EHs are inserted 137 directly after the IPv6 fixed header. 139 For IPv6 tunnel packets [RFC2473], where they may be two or more 140 instances of an IPv6 fixed header throughout the packet, EH insertion 141 could be occurring between any of the IPv6 fixed headers and their 142 respective following payloads, although it is most likey to occur 143 after the first of the IPv6 fixed header, commonly known as the 144 (outer) tunnel header. 146 An example of where this in-flight EH insertion may take place is 147 when a packet enters a transit BGP autonomous system network 148 [RFC4271] along its path across the Internet. 150 3.2. In-Flight Removal 152 At some later point along the IPv6 packet's path towards its final 153 destination, the packet is somehow determined to need to have the 154 prevously inserted EH removed, independently of the Destination 155 Address of the packet. The packet is again split apart, at the point 156 where the one or more inserted EHs exists, and then the inserted EH 157 or EHs are removed. The packet is then reassembled, and sent further 158 towards its final destination. 160 Again, the packet's original source and Destination Address field 161 values are left unchanged when EH removal takes place. As with 162 insertion, the likely only IPv6 fixed header field modified during EH 163 removal would be the immutable Next Header field. 165 An example of where this in-flight EH removal would take place is 166 when a packet leaves a transit BGP autonomous system network that has 167 previously inserted one or more EHs. 169 3.3. In-Flight Insertion Without Removal 171 A possibility is that in-flight insertion of the EH occurs without 172 the intention that it is subsequently removed while the packet is in- 173 flight. 175 In this instance, the device that is intended to process the inserted 176 EH is the IPv6 host identified in the packet's (unchanged) 177 Destination Address field. 179 4. EH Removal Failure Causes 181 4.1. Implementation Bugs 183 Despite being configured to remove the inserted one or more EHs, an 184 implementation bug could cause some or all packets not to have the 185 inserted EH or EHs removed. 187 4.2. Partial Node Failure 189 Even though the software or firmware that is to perform EH removal is 190 bug free, it is possible that a hardware fault could cause EH removal 191 to not occur, while packets are still sent towards their final 192 destinaton. This could occur because the hardware fault that does 193 not cause the node to entirely fail, only partially performing some 194 of its functions.. 196 4.3. Operator Configuration Error 198 Due to human error, the function to remove the inserted EH or EHs may 199 be misconfigured. Consequently, the inserted EH or EHs may not be 200 removed for some or all packets. 202 When the packets to have the EH(s) removed are transit packets, 203 meaning these packets are likely leaving the operator's own network, 204 and entering another operator's network, it is less likely that the 205 packets leaving are inspected to ensure the EH removal function has 206 been configured correctly. It is common to assume that if traffic is 207 leaving the local network in the expected volumes, then the traffic 208 is being processed correctly by the egress network device. This can 209 be because the equipment, time and effort to validate this egressing 210 traffic can be very expensive when traffic volumes are in the 10s or 211 perhaps 100s of gigabits per second. 213 The receiving network will also not detect or be able to detect that 214 the inserted EHs have not been removed, as the inserted EH or EHs 215 will appear to have been placed in the packet by the IPv6 host 216 identified in the packet's Source Address field. 218 5. Single Point of Failure 220 When functions that inspect or modify packets beyond standard IP 221 packet forwarding are performed at the edge of a network, such as a 222 network firewall or a Network Address Translation, it is typical for 223 there to only be one device performing that will perform this 224 function at the packets' exit from the network. It is rare to have 225 two devices in-line or in series that are performing this same 226 inspection or modification, providing redundancy for the function 227 should it fail to be performed correctly at the first function 228 instance. 230 In a scenario where EHs are to be removed, it is likely that the 231 device that is to perform EH removal will be a single point of 232 failure. 234 6. MUST Remove is Aspirational 236 RFCs/IDs say the inserted EH MUST be removed at the EH insertion 237 boundary, and then use that to say it is a safe operation. This is 238 ignoring the reality of all of the above possible causes of an 239 inserted EH failing to be removed. Such a MUST statement is no more 240 than aspirational - it is a theoretically true statement in 100% of 241 cases, but in practice cannot ever be assured to be true in 100% of 242 cases, due to the removal failure causes, described previously. 244 7. Harm 246 7.1. Violates RFC8200 and All Of Its Ancestors. 248 (RFC8200 EH processing text quote) 250 RFC 2460 and ancestors back to RFC 1883 text quote. 252 7.2. Ignores Source Address Field Semantics 254 7.3. Breaks ICMPv6 256 7.3.1. Breaks PMTUD 258 7.4. Breaks IPsec 260 7.5. May Cause Faults in Subsequent Transit Networks 262 If an in-flight inserted EH is not removed, and the packet travels 263 into another subsequent transit network, that subsequent transit 264 network may have an alternative interpretation of the inserted EH, 265 causing a fault. 267 The subsequent transit network, if using EH insertion, would likely 268 blindly insert another instance of the EH, resulting in a packet with 269 two EHs. At network egress, the incorrect EH may removed, which 270 would also still leave a remaining inserted EH to travel into further 271 subsequent networks. A directly subsequent network that is also 272 performing EH insertion is unlikely to act as a sanitser for EHs that 273 were inserted by previous upstream networks. 275 7.6. Incorrect Destination Host Processing 277 Should an in-flight inserted EH fail to be removed, the receiving 278 IPv6 host may process it incorrectly. Incorrect processing could 279 involve discarding the packet when it should be further processed, or 280 processing the packet when it should be discarded. 282 An failed to be removed, in-flight inserted EH is less likely to be 283 understood by a typical receiving IPv6 host, as the inserted EH is 284 being used for a network function. 286 If an IPv6 host receives an EH that it doesn't understand, how to 287 process the EH is encoded in the highest order two bits of the EH 288 type [RFC8200]. If the highest order bits are all zeros, skip this 289 EH and continue processing the header. If the highest order bits are 290 01, discard the packet. If the highest order bits are 10 or 11, then 291 discard the packet, and either universally generate and send an ICMP 292 Parameter Problem for all Destination Address types, or for the 293 latter value, generate and send an ICMP Parameter Problem for only 294 non-multicast Destination Addresses. 296 A failed to be removed, in-flight inserted EH may not have these 297 highest order bits set correctly to best suit the application's and 298 its end-user's goals. 300 For example, if the packet was carrying a streaming video 301 application's data, then an unknown inserted EH, yet failed to be 302 removed network function EH may be harmless to the application and 303 its end-user if it can be skipped over by the receiving IPv6 host. 304 However, if the inserted yet not-removed EH has non-zero highest 305 order bits, the packet would be discarded, causing the video data not 306 to be displayed to the end-user, despite there being no harm in doing 307 so. 309 Alternatively, there could be cases where the inserted, yet failed to 310 be removed EH should cause a packet to be discarded by the host with 311 the Destination Address, perhaps for security reasons. However, if 312 the inserted EH has highest order two bits that are all zero, meaning 313 ignore the unknown EH and continue processing the header, the packet 314 will instead by further processed by the receiving IPv6 host. 315 Perhaps the packet will be further processed in a way that violates a 316 security policy that should be being enforced when the inserted, yet 317 failed to be removed EH is being processed. 319 7.7. Implementation Complexity 321 IPv6 uses a packet's Destination Address to determine the point where 322 forwarding across the network stops, and processing up the protocol 323 stack at a destination host starts. 325 In other words, the Destination Address of a packet identifies the 326 point in the network where processing of the packet starts going 327 beyond the IPv6 fixed header, and where the intention of the packet 328 processing stops being limited to forwarding towards the packet's 329 destination. 331 This is the fundamental distinction between an IPv6 router and a 332 host; an IPv6 router forwards packets with non-local addresses 333 [RFC8200], while an IPv6 host, with that holds address that matches a 334 packet's Destination Address, processes the packet locally, with 335 processing occuring beyond the IPv6 packet's fixed header. Note that 336 these definitions of IPv6 router and host are functional; a router as 337 a device implements both IPv6 router and host functions - the 338 device's forwarding plane implementing the IPv6 router function, and 339 the device's control plane implementing IPv6 host functions. 341 This means that all IPv6 addresses that appear in an IPv6 packet's 342 Source Address and Destination Address field are, without exception, 343 host addresses. 345 The decision as to whether to process the packet beyond the fixed 346 header or not is binary and simple - does the current node holding 347 the packet possess the IPv6 address recorded in the Destination 348 Address field of the packet? 350 Identifying packets that have had EH's inserted, to then remove and 351 process the EH, is much more complex than the simple, Destination 352 Address match selector. The EH chain inside each packet has to be 353 processed to find the EH that was inserted, should it exist. 355 7.8. Costly Troubleshooting 357 The lack of attribution of which device inserted the EH could incur 358 high costs during troubleshooting, in terms of time, effort and 359 financially for a commercially operated network, should EH removal 360 fail. 362 Imagine a scenario where there is a popular streaming video on demand 363 (SVOD) content service on the Internet providing content to large 364 number of customers at a residential "eyeball" ISP. Between the SVOD 365 network and the ISP network, there are 8 different transit networks. 367 One or more of those transit networks decides to implement a local 368 function using EH insertion. Unfortunately, EH removal at the egress 369 of one or possibly more of these transit networks fails, due to one 370 of the possible causes mentioned previously. This or these failures 371 occurs somewhere in the path from the SVOD network to the ISP 372 network. 374 As the Destination Address of this packet is as it was when the SVOD 375 network sent the packet, prior to when the EH was inserted while in 376 transit, this packet will continue to be forwarded and then delivered 377 to the destination host at the ISP network. 379 When the packet arrives at the destination host, the host is required 380 to process the Extension Headers in order [RFC8200]. Should an 381 Extension Header be encountered that the host does not recognise, the 382 host may discard the packet based on the two highest order bits of 383 the EH type. The packet's video data will not be available to the 384 video application and will not be displayed to the end-user. 386 As the transit network(s) that inserted the EH, yet failed to remove 387 it may be carrying the SVOD traffic for 100s or 1000s of customers at 388 the residential ISP, 100s or 1000s of customers will fail to receive 389 their SVOD service. These customers will either contact the support 390 helpdesk of the ISP or the support helpdesk of the SVOD service to 391 report the fault. 393 In either case, the network operators trying to resolve this faul 394 will have no indication which of the 8 transit networks is inserting 395 the EH yet failing to remove it. 397 Consequently, the only way to troubleshoot this is through a brute- 398 force process of elimination. It would be necessary to contact all 399 of the 8 transit networks, and ask them if they're inserting EHs 400 while packets are in-flight. If they are, then it may be necessary 401 to convince them that their inserted EHs are failing to be removed at 402 the egress of their network, as they may be sceptical, since there 403 are no local effects of the fault. Providing a packet capture with 404 the inserted EH that is causing the fault does not provide any 405 supporting evidence to show that a specific transit network is 406 failing to remove inserted EHs. 408 Once the operator or operators of the networks that are inserting EHs 409 are convinced that their network may not be removing EHs, those 410 operators will now have to arrange to inspect the traffic leaving 411 their network, after it has been sent by their network's egress 412 device. 414 Organising and executing this traffic inspection is likely to be time 415 and possibly resource intensive. The egress transit link attached to 416 the device that is failing to remove the inserted EHs may be carrying 417 10s or perhaps 100 or more Gbps of transit traffic. Inserting a 418 traffic inspection device within the link will cause this traffic to 419 shift to other links if available, either when the link is broken, or 420 in preparation for breaking the link. 422 As this will be a service impacting event, it will likely need to go 423 through change management procedures for review. Given the event's 424 severity, service impact notification may involve a number of days, 425 prior the event being executed. 427 Once the faulty device has been identified, it needs to be rectified. 428 This may involve rectification by the device's vendor if the fault 429 cause is a software or firmware bug. 431 Given the above troubleshooting process, the amount of parties 432 involved, and the time it could take to perform the troubleshooting 433 and rectification steps, in this scenario, troubleshooting and 434 rectification would likely take in the order of at least a week, if 435 not a number of weeks. This will have a very significant business 436 impact on either or both of the SVOD provider or the residential ISP, 437 both in terms of market preception and lost customers, frustrated 438 with how long this fault is taking to resolve to the point where they 439 cancel their service. 441 8. Be conservative in what you send, ... 443 i.e. Postel's law 445 "Be conservative in what you send, ..." is saying try to avoid 446 sending anything that the receiver may not be expecting and that may 447 confuse the receiver. The "be liberal in what you accept" is 448 advising robustness to attempt to tolerate a sender that has failed 449 to be conservative. 451 In-flight EH insertion violates the conservative sender part, because 452 [RFC8200] compliant receivers are not expecting to receive EHs in a 453 packet that were not placed there by the device identified in the 454 packet's Source Address field. A device performing in-flight EH 455 insertion is intentionally not being conservative with what it is 456 sending, in comparison to the scope of what an [RFC8200] compliant 457 receiver expects to receive. 459 9. Solution: Encapsulation 461 In the Internet Protocol Architecture [RFC1122][RFC6272], adding new 462 information to an existing protocol data unit is achieved through 463 encapsulation. The new information is recorded in a new header and 464 possibly a new trailer, which are then used to surround or enclose 465 the existing protocol data unit, similar to how an envelope is used 466 to enclose the contents of a letter in the physical mail system. 468 In addition to other new information, the new encapsulation header 469 records the source of that new information. For the link-layer that 470 is the source node's link-layer address; for the IP layer it is 471 either the IPv4 or IPv6 source host's address; and for the transport 472 layer, it is the source transport layer port, or some other transport 473 layer source entity identifier. 475 The new encapsulation also records the destination entity or entities 476 that is or are intended to receive and process the new information. 477 For the link-layer, the destination node's link-layer address, or a 478 single group address that identifies a set of link-layer nodes; for 479 the IP layer, the IPv4 or IPv6 destination host, or a single group 480 address that identifies a set of hosts; and for the transport layer, 481 the destination transport layer port or other transport layer 482 destination entity identifier. 484 The source and destination entity identification in the encapsulation 485 header provides unambiguous and explicit identification of both which 486 entity created and sent the new information, and which entity or 487 entities are to process the new information. 489 9.1. IPv6 Tunnelling 491 If additional IPv6 information is to be added to an existing IPv6 492 packet while it is in-flight, such as a new Extenstion Header, then a 493 new IPv6 header is required. This new IPv6 header will unambiguously 494 record the identity of the IPv6 host that has added the new IPv6 495 information in the Source Address field, and will unambigously record 496 the identity of the IPv6 host (or group of hosts) that is to process 497 the added IPv6 information in the Destination Address field. A new 498 IPv6 packet is created using the new IPv6 header, followed by the new 499 supplimentary information, followed by the existing IPv6 packet, 500 appearing in the payload field of the new packet. IPv6-in-IPv6 501 encapsulation is commonly known as "tunneling", and is specified in 502 [RFC2473], which includes showing how new information added via 503 Extension Headers occurs. [intarea-tunnels] provides more discussion 504 of IP tunneling in the context of the Internet Architecture. 506 Conceptually, IPv6-in-IPv6 tunneling is a form of link-layer 507 encapsulation from the perspective of the existing (and eventually 508 inner) IPv6 packet. It just happens to be a coincidence that the 509 outer link-layer encapsulation header and other new information (i.e. 510 Extension Headers) has the same protocol format and field sematics as 511 the existing, inner IPv6 packet. 513 9.2. MPLS 515 Despite using terms such as "label imposition" or "label swapping", 516 MPLS [RFC3031] also follows this encapsulation model to add new 517 information, via labels, to an existing in-flight protocol data unit, 518 such as an IPv6 packet. In-flight insertion of MPLS labels never 519 occurs. 521 At each hop through the MPLS network where labels are processed, at 522 devices known as Label Switching Routers (LSRs), upon egress from the 523 LSR, a new link-layer header is created that both unambiguously 524 identifies the current LSR in the link-layer Source Address field, 525 and unambiguously identifies the next LSR (or set of LSRs) that is to 526 process the set of labels that are encoded in the link-layer protocol 527 data unit sent by the current LSR. The labels are encoded following 528 this new header, and then the original packet follows in the link- 529 layer payload field. 531 If in-flight MPLS label insertion were to be actually occurring, then 532 it would mean that as a packet was label switched across a set of 533 LSRs along a Label Switched Path (LSP), the link-layer header Source 534 Address would not change across the LSP - it would remain as the 535 Source Address of the LSR at the head end of the LSP, regardless of 536 how many subsequent LSRs the packet is label switched through. 538 In-flight MPLS label insertion would also mean that the Destination 539 Address in the link-layer header would also not change as the packet 540 is label switched along the LSP. It would remain unchanged 541 regardless of how many LSRs the packet traverses, and would likely 542 identify the final LSR at the tail end of the LSP. 544 If MPLS had used an in-flight insertion model, then MPLS would have 545 likely suffered from problems similar to those described above that 546 can occur with IPv6 EH insertion. 548 10. Reducing Tunneling Overhead 550 As a tunnel is creating a virtual link layer, link-layer compression 551 of the inner IPv6 header and its payload can be used to effectively 552 reduce the tunneling overhead. 554 10.1. ROHC 556 "The Robust Header Compression (ROHC) protocol provides an efficient, 557 flexible, and future-proof header compression concept. It is 558 designed to operate efficiently and robustly over various link 559 technologies with different characteristics." [RFC5795] 561 10.2. Skinny IPv6-in-IPv6 Tunneling 563 Skinny-IPv6-in-IPv6 tunnelling [SKINNYV6V6] is a stateless form of 564 tunnelling compression that leverages two charateristics of IPv6 and 565 IPv6 networks: 567 o The common semantics between the inner IPv6 and outer IPv6 tunnel 568 packet's headers. While the inner IPv6 packet is in flight over 569 the IPv6 tunnel, the large majority of its header field values are 570 carried and proxied by the outer IPv6 tunnel header's 571 corresponding fields. 573 o The availability of many /64 prefixes within an IPv6 network, 574 using /64s rather than /128s to identify IPv6 tunnel end-points. 575 This allows the inner packet's 64 bit IIDs to be carried in the 576 outer IPv6 tunnel packet's IID fields while the inner packet is 577 carried over the IPv6 tunnel. 579 11. In-Flight Insertion Considered Harmful 581 More generally, insertion within an existing, in-flight packet at any 582 location within the packet is considered harmful. EH insertion, as 583 described and discussed previously, is a more specific instance of a 584 harmful practise. 586 12. Security Considerations 588 13. Acknowledgements 590 Review and comments were provided by YOUR NAME HERE! 592 This memo was prepared using the xml2rfc tool. 594 14. Change Log [RFC Editor please remove] 596 draft-smith-6man-in-flight-eh-insertion-harmful-00, initial version, 597 2019-09-09 599 draft-smith-6man-in-flight-eh-insertion-harmful-01, update, 600 2019-11-03 602 o Added co-authors 604 o Link-layer compression section 606 o Costly troubleshooting scenario section 608 draft-smith-6man-in-flight-eh-insertion-harmful-01, update, 609 2019-11-03 611 o Version bump. Request for WG adoption per discussion at IETF 106. 613 15. References 614 15.1. Normative References 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, 618 DOI 10.17487/RFC2119, March 1997, 619 . 621 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 622 (IPv6) Specification", STD 86, RFC 8200, 623 DOI 10.17487/RFC8200, July 2017, 624 . 626 15.2. Informative References 628 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 629 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 630 December 1998, . 632 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 633 Header Compression (ROHC) Framework", RFC 5795, 634 DOI 10.17487/RFC5795, March 2010, 635 . 637 [SKINNYV6V6] 638 "Skinny IPv6 in IPv6 Tunnelling", 639 . 642 Authors' Addresses 644 Mark Smith 645 PO Box 521 646 Heidelberg, VIC 3084 647 AU 649 Email: markzzzsmith@gmail.com 651 Naveen Kottapalli 653 Email: naveen.sarma@gmail.com 654 Ron Bonica 655 Juniper Networks 656 2251 Corporate Park Drive 657 Herndon, Virginia 20171 658 USA 660 Email: rbonica@juniper.net 662 Fernando Gont 663 SI6 Networks 664 Evaristo Carriego 2644 665 Haedo, Provincia de Buenos Aires 666 Argentina 668 Email: fgont@si6networks.com 670 Tom Herbert 671 Quantonium 672 Internet Road 673 Santa Clara, CA 674 USA 676 Email: tom@quantonium.net