idnits 2.17.1 draft-leddy-6man-truncate-05.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2018) is 2020 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man J. Leddy 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track R. Bonica 5 Expires: April 15, 2019 Juniper Networks 6 I. Lubashev 7 Akamai Technologies 8 October 12, 2018 10 IPv6 Packet Truncation 11 draft-leddy-6man-truncate-05 13 Abstract 15 This document defines IPv6 packet truncation procedures. These 16 procedures make Path MTU Discovery (PMTUD) more reliable. Upper- 17 layer protocols can leverage these procedures in order to take 18 advantage of large MTUs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 15, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 56 3. Operational Considerations . . . . . . . . . . . . . . . . . 5 57 4. IPv6 Destination Options . . . . . . . . . . . . . . . . . . 6 58 4.1. The Truncation Eligible Option . . . . . . . . . . . . . 6 59 4.2. The Truncated Packet Option . . . . . . . . . . . . . . . 7 60 5. Reference Topology . . . . . . . . . . . . . . . . . . . . . 8 61 6. Truncation Procedures . . . . . . . . . . . . . . . . . . . . 8 62 7. Additional Truncation Considerations . . . . . . . . . . . . 10 63 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10 64 9. Checksum Considerations . . . . . . . . . . . . . . . . . . . 11 65 10. Invalid Packet Types . . . . . . . . . . . . . . . . . . . . 11 66 11. Network Considerations . . . . . . . . . . . . . . . . . . . 12 67 12. Encapsulating Security Payload Considerations . . . . . . . . 12 68 13. Extension Header Considerations . . . . . . . . . . . . . . . 13 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 17.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 17.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 An Internet path connects a source node to a destination node. A 80 path can contain links and routers. 82 Each link is constrained by the number of bytes that it can convey in 83 a single IP packet. This constraint is called the link Maximum 84 Transmission Unit (MTU). IPv6 [RFC8200] requires every link to have 85 an MTU of 1280 bytes or greater. This value is called IPv6 minimum 86 link MTU. 88 Likewise, each Internet path is constrained by the number of bytes 89 that it can convey in a single IP packet. This constraint is called 90 the Path MTU (PMTU). For any given path, the PMTU is equal to the 91 smallest of its link MTUs. 93 IPv6 allows fragmentation at the source node only. If an IPv6 source 94 node sends a packet whose length exceeds the PMTU, an intermediate 95 node will discard the packet. In order to prevent this, IPv6 nodes 96 can either: 98 o Refrain from sending packets whose length exceeds the IPv6 minimum 99 link MTU. 101 o Maintain a running estimate of the PMTU and refrain from sending 102 packets whose length exceeds that estimate. 104 In order to maintain a running estimate of the PMTU, IPv6 nodes can 105 execute Path MTU Discovery (PMTUD) [RFC8201] procedures. In these 106 procedures, the source node produces an initial PMTU estimate. This 107 initial estimate equals the MTU of the first link along the path to 108 the destination. It can be greater than the actual PMTU. 110 Having produced an initial PMTU estimate, the source node sends 111 packets to the destination node. If one of these packets is larger 112 than the actual PMTU, an intermediate node will not be able to 113 forward the packet through the next link along the path. Therefore, 114 the intermediate node discards the packet and sends an Internet 115 Control Message Protocol (ICMP) [RFC4443] Packet Too Big (PTB) 116 message to the source node. The ICMP PTB message indicates the MTU 117 of the link through which the packet could not be forwarded. The 118 source node uses this information to refine its PMTU estimate. 120 PMTUD relies on the network to deliver ICMP PTB messages from the 121 intermediate node to the source node. If the network cannot deliver 122 these messages, a persistent black hole can develop. In this 123 scenario, the source node sends a packet whose length exceeds the 124 PMTU. An intermediate node discards the packet and sends an ICMP PTB 125 message to the source. However, the network cannot deliver the ICMP 126 PTB message to the source. Therefore, the source node does not 127 update its PMTU estimate and it continues to send packets whose 128 length exceeds the PMTU. The intermediate node discards these 129 packets and sends more ICMP PTB messages to the source. These ICMP 130 PTB messages are lost, exactly as previous ICMP PTB messages were 131 lost. 133 In some operational scenarios (Section 3), networks cannot deliver 134 ICMP PTB messages from an intermediate node to the source node. 135 Therefore, enhanced procedures are required. 137 This document defines IPv6 packet truncation procedures. When an 138 IPv6 source node originates a packet, it executes the following 139 procedure: 141 o Mark the packet as being eligible for truncation. 143 o Forward the packet towards its destination. 145 If an intermediate node cannot forward the packet because of an MTU 146 issue, it executes the following procedure: 148 o Detect that the packet is eligible for truncation. 150 o Send an ICMP PTB message to the source node, with the MTU field 151 indicating the MTU of the link through which the packet could not 152 be forwarded. 154 o Truncate the packet. 156 o Mark the packet as being truncated. 158 o Update the packet's upper-layer checksum (if possible). 160 o Forward the packet towards its destination. 162 When the destination node receives the packet, it executes the 163 following procedure: 165 o Detect that the packet has been truncated. 167 o Send an ICMP PTB message to the source node, with the MTU field 168 indicating the length of the truncated packet. 170 o Discard the packet. 172 Both ICMP PTB messages, mentioned above, contain MTU information that 173 the source node can use to refine its PMTU estimate. 175 The procedures described herein prevent incomplete (i.e., truncated) 176 data from being delivered to upper-layer protocols. While IPv6 177 packet truncation may facilitate new upper-layer procedures, upper- 178 layer procedures are beyond the scope of this document. 180 The procedures described herein make PMTUD more reliable by 181 increasing the probability that the source node will receive ICMP PTB 182 feedback from a downstream device. Even when the network cannot 183 deliver ICMP PTB messages from an intermediate router to a source 184 node, it may be able to deliver an ICMP PTB messages from the 185 destination node to the source node. 187 However, the procedures described herein do not make PMTUD one 188 hundred per cent reliable. In some operational scenarios, the 189 network cannot deliver any ICMP messages to the source node, 190 regardless of their origin. 192 2. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 196 "OPTIONAL" in this document are to be interpreted as described in BCP 197 14 [RFC2119] [RFC8174] when, and only when, they appear in all 198 capitals, as shown here. 200 3. Operational Considerations 202 The packet truncation procedures described herein make PMTUD more 203 resilient when: 205 o The network can deliver ICMP messages from the destination node to 206 the source node. 208 o The network cannot deliver ICMP messages from an intermediate node 209 to the source node. 211 The following are common operational scenarios in which packet 212 truncation procedures can make PMTUD more resilient: 214 o The destination node has a viable route to the source node, but 215 the intermediate node does not. 217 o The source node is protected by a firewall that administratively 218 blocks all packets except for those from specified subnetworks. 219 The destination node resides in one of the specified subnetworks, 220 but the intermediate node does not. 222 o The source address of the original packet (i.e., the packet that 223 elicited the ICMP message) was an anycast address. Therefore, the 224 destination address of the ICMP message is the same anycast 225 address. In this case, an ICMP message from the destination node 226 is likely to be delivered to the correct anycast instance. By 227 contrast, an ICMP message from an intermediate node is less likely 228 to be delivered to the correct anycast instance. 230 Packet truncation procedures do not make PMTUD more resilient when 231 the network cannot reliably deliver any ICMP messages to the source 232 node. The following are operational scenarios where the network 233 cannot reliably deliver any ICMP PTB messages to the source node: 235 o The source node is protected by a firewall that administratively 236 blocks all ICMP messages. 238 o The source node is an anycast instance served by a load-balancer 239 as defined in [RFC7690]. The load-balancer does not implement the 240 mitigations defined in [RFC7690]. 242 4. IPv6 Destination Options 244 This document defines the following IPv6 Destination options: 246 4.1. The Truncation Eligible Option 248 The Truncation Eligible option indicates that the packet is eligible 249 for truncation. It also indicates that the packet has not been 250 truncated. 252 The Truncation Eligible option contains the following fields: 254 o Option Type - Truncation Eligible option. Value TBD by IANA. See 255 Notes below. 257 o Opt Data Len - Length of Option Data, measured in bytes. MUST be 258 equal to 0. 260 IPv6 packets that include the Fragment header MUST NOT include the 261 Truncation Eligible option. 263 IPv6 packets whose length is less than the IPv6 minimum link MTU 264 SHOULD NOT include the Truncation Eligible option. 266 The IPv6 Hop-by-hop Options header SHOULD NOT include the Truncation 267 Eligible option. 269 The IPv6 Destination Options header: 271 o MAY include a single instance of the Truncation Eligible option. 273 o SHOULD NOT include multiple instances of the Truncation Eligible 274 option. 276 o MUST NOT include both the Truncation Eligible option and the 277 Truncated Packet option (Section 4.2). 279 NOTE 1: According to [RFC8200], the highest-order two bits of the 280 Option Type (i.e., the "act" bits) specify the action taken by a 281 processing node that does not recognize Option Type. The required 282 action is skip over this option and continue processing the header. 283 Therefore, IANA is requested to assign this Option Type with "act" 284 bits "00". 286 NOTE 2: According to [RFC8200], the third-highest-order bit (i.e., 287 the "chg" bit) of the Option Type specifies whether Option Data can 288 change on route to the packet's destination. Because this option 289 contains no Option Data, IANA can assign this Option Type without 290 regard to the "chg" bit. 292 4.2. The Truncated Packet Option 294 The Truncated Packet option indicates that the packet has been 295 truncated and is eligible for further truncation. 297 The Truncated Packet option contains the following fields: 299 o Option Type - Truncated Packet option. Value TBD by IANA. See 300 Notes below. 302 o Opt Data Len - Length of Option Data, measured in bytes. MUST be 303 equal to 0. 305 IPv6 packets that include the Fragment header MUST NOT include the 306 Truncated Packet option. 308 IPv6 packets whose length is less than the IPv6 minimum link MTU MUST 309 NOT include the Truncated Packet option. 311 The IPv6 Hop-by-hop Options header SHOULD NOT include the Truncated 312 Packet option. 314 The IPv6 Destination Options: 316 o MAY include a single instance of the Truncated Packet option. 318 o SHOULD NOT include multiple instances of the Truncated Packet 319 option. 321 o MUST NOT include both the Truncated Packet option and the 322 Truncation Eligible option. 324 NOTE 1: According to [RFC8200], the highest-order two bits of the 325 Option Type (i.e., the "act" bits) specify the action taken by a 326 processing node that does not recognize Option Type. The required 327 action is to discard the packet and send an ICMP Parameter Problem, 328 Code 2, message to the packet's Source Address, pointing to the 329 unrecognized Option Type. Therefore, IANA is requested to assign 330 this Option Type with "act" bits "10". 332 NOTE 2: According to [RFC8200], the third-highest-order bit (i.e., 333 the "chg" bit) of the Option Type specifies whether Option Data of 334 that option can change on route to the packet's destination. Because 335 this option contains no Option Data, IANA can assign this Option Type 336 without regard to the "chg" bit. 338 5. Reference Topology 340 ----------- ----------- ----------- ----------- 341 | Upper | | | | | | Upper | 342 | Layer | | | | | | Layer | 343 | | | | | | | | 344 | IP |<-------->| IP |<-------->| IP |<-------->| IP | 345 | Layer | MTU | Layer | MTU | Layer | MTU | Layer | 346 ----------- 9000 ----------- 4000 ----------- 1500 ----------- 347 Source Router 1 Router 2 Destination 348 Node Node 350 Figure 1: Reference Topology 352 Figure 1 depicts a network that contains a Source Node, intermediate 353 nodes (i.e., Router 1, Router 2), and a Destination Node. The link 354 that connects the Source Node to Router 1 has an MTU of 9000 bytes. 355 The link that connects Router 1 to Router 2 has an MTU of 4000 bytes, 356 and the link that connects Router 2 to the Destination Node has an 357 MTU of 1500 bytes. The PMTU between the Source Node and the 358 Destination Node is 1500 bytes. 360 This topology is used in examples throughout the document. 362 6. Truncation Procedures 364 In the Reference Topology (Figure 1), the Source Node produces an 365 initial estimate of the PMTU between itself and the Destination Node. 366 This initial estimate equals the MTU of the first link on the path to 367 the Destination Node (e.g., 9000 bytes). 369 The Source Node refrains from sending packets whose length exceeds 370 the above-mentioned estimate. However, the above-mentioned estimate 371 is significantly larger than the actual PMTU (1500 bytes). 372 Therefore, the Source Node may send packets whose length exceeds the 373 actual PMTU. 375 At some time in the future, an upper-layer protocol on the Source 376 Node causes the IP layer to emit a packet. The packet contains a 377 Destination Options header and the Destination Options header 378 contains a Truncation Eligible option. The total packet length, 379 including all headers and the payload, is 1350 bytes. Because the 380 total packet length is less than the actual PMTU, this packet can be 381 delivered to the Destination Node without encountering any MTU 382 issues. 384 The IP layer on the Source Node forwards the packet to the Router 1, 385 Router 1 forwards the packet to Router 2, and the Router 2 forwards 386 the packet to the Destination Node. The IP layer on the Destination 387 Node examines the Destination Options header and finds the Truncation 388 Eligible option. The Truncation Eligible option requires no action 389 by the Destination Node. Therefore, the Destination Node processes 390 the next header and delivers the packet to an upper-layer protocol. 392 Subsequently, the same upper-layer protocol on the Source Node causes 393 the IP layer to emit another packet. This packet is identical to the 394 first, except that the total packet length is 2000 bytes. Because 395 the packet length is greater than the actual PMTU, this packet cannot 396 be delivered without encountering an MTU issue. 398 The IP layer on the source node forwards the packet to Router 1. 399 Router 1 forwards the packet to Router 2, but the Router 2 cannot 400 forward the packet because its length exceeds the MTU of the next 401 link in the path (i.e., 1500 bytes). Because an MTU issue has been 402 encountered, Router 2 examines the Destination Options header, 403 searching for either a Truncation Eligible option or a Truncated 404 Packet option. (Normally, the Router 2 would ignore the Destination 405 Options header). 407 Because Router 2 finds one of the above-mentioned options, it: 409 o Sends an ICMP PTB message to the Source Node. The ICMP PTB 410 message contains an MTU field indicating the MTU of the next link 411 in the path (i.e. 1500 bytes). 413 o Truncates the packet, so that its total length equals the MTU of 414 the next link in the path. 416 o Updates the IPv6 Payload Length. 418 o Overwrites all instances of the Truncation Eligible option with a 419 Truncated Packet option. 421 o Updates the upper-layer checksum (if possible) 423 o Forwards the packet to the Destination Node. 425 The IP layer on the Destination Node receives the packet and examines 426 the Destination Options header. Because it finds the Truncated 427 Packet option, it discards the packet and sends an ICMP PTB message 428 to the Source Node. The MTU field in the ICMP PTB message represents 429 the length of the received packet. 431 When the Source Node receives the ICMP PTB message, it updates its 432 PMTU estimate, as per [RFC8201]. 434 7. Additional Truncation Considerations 436 A packet can be truncated multiple times. In the Reference Topology 437 (Figure 1), assume that the Source Node sends a 5000 byte packet to 438 the Destination Node. Using the procedures described in Section 6, 439 Router 1 truncates this packet to 4000 bytes and Router 2 truncates 440 it again, to 1500 bytes. 442 A truncated packet MUST contain the basic IPv6 header, all extension 443 headers and the first upper-layer header. When an intermediate node 444 cannot forward a packet due to MTU issues, and the total length of 445 the basic IPv6 header, all extension headers, and first upper-layer 446 header exceeds the MTU of the next link in the path, the intermediate 447 node MUST discard the packet and send and ICMP PTB message to the 448 source node. It MUST NOT truncate the packet. 450 A truncated packet MUST NOT include the Fragment header. When an 451 intermediate node cannot forward a packet due to MTU issues, and the 452 packet contains a Fragment header, the intermediate node MUST discard 453 the packet and send and ICMP PTB message to the source node. It MUST 454 NOT truncate the packet. 456 A truncated packet must have a total length that is greater than or 457 equal to the IPv6 minimum link MTU. 459 8. Backwards Compatibility 461 Section 6 of this document assumes that all nodes recognize the 462 Truncation Eligible and Truncated Packet options. This section 463 explores backwards compatibility issues, where one or more nodes do 464 not recognize the above-mentioned options. 466 An intermediate node that does not recognize the above-mentioned 467 options behaves exactly as described in [RFC8200]. When it receives 468 a packet that does not cause an MTU issue, it processes the packet. 469 When it receives a packet that causes an MTU issue, it discards the 470 packet and sends an ICMP PTB message to the source node. In neither 471 case does the intermediate node examine the Destination Options 472 header or truncate the packet. 474 A destination node that does not recognize the Truncation Eligible 475 option also behaves exactly as described in [RFC8200]. When it 476 receives a packet that contains the Truncation Eligible option, its 477 behavior is determined by the highest-order two bits of the Option 478 Type (i.e., the "act" bits). Because the "act" bits are equal to 479 "00", the destination node skips over the option and continues to 480 process the packet. This is exactly what the destination node would 481 have done if it had recognized the Truncation Eligible option. 483 A destination node that does not recognize the Truncated Packet 484 option also behaves exactly as described in [RFC8200]. When it 485 receives a packet that contains the Truncated Packet option, its 486 behavior is determined by the highest-order two bits of the Option 487 Type (i.e., the "act" bits). Because the "act" bits are equal to 488 "10", the destination node discards the packet and sends an ICMP 489 Parameter Problem, Code 2, message to the packet's Source Address, 490 pointing to the Truncated Packet option. The destination node does 491 not emit an ICMP PTB message. 493 The source node takes appropriate action when it receives the ICMP 494 Parameter Problem message. 496 9. Checksum Considerations 498 When an intermediate node truncates a packet, it SHOULD update the 499 upper-layer checksum, if possible. This is desirable because it 500 increases the probability that the truncated packet will be delivered 501 to the destination node. 503 Middleboxes residing downstream of the intermediate node may attempt 504 to validate the upper-layer checksum. If validation fails, they may 505 discard the packet without sending an ICMP message. 507 10. Invalid Packet Types 509 The following packet types are invalid: 511 o Packets that contain the Fragment header and the Truncation 512 Eligible option. 514 o Packets that contain the Fragment header and the Packet Truncated 515 option. 517 o Packets that contain the Truncation Eligible option and the Packet 518 Truncated option. 520 o Packets that specify an Option Data Length greater than 0 in the 521 Truncation Eligible option. 523 o Packets that specify an Option Data Length greater than 0 in the 524 Truncated Packet option. 526 o Packets that have a total length less than the IPv6 minimum link 527 MTU and contain the Packet Truncated option. 529 If an intermediate node cannot forward one of the above-mentioned 530 packets because of an MTU issue, its behavior is as described in 531 [RFC8200]. The intermediate node discards the packet and sends an 532 ICMP PTB message to the source node. It does not truncate or forward 533 the packet. 535 When the destination node receives one of the above-mentioned 536 packets, it MUST: 538 o Discard the packet 540 o Send an ICMP Parameter Problem, Code 2, message to the packet's 541 Source Address, pointing to the first invalid option. 543 The destination node MUST NOT send an ICMP PTB message. 545 11. Network Considerations 547 The procedures described herein rely upon the networks ability: 549 o To convey packets that contain destination options from the source 550 node to the destination node. 552 o To convey ICMP Parameter Problem messages in the reverse 553 direction. 555 Operational experience [RFC7872] reveals that a significant number of 556 networks drop packets that contain IPv6 destination options. 557 Likewise, many networks drop ICMP Parameter Problem messages. 559 [I-D.bonica-6man-unrecognized-opt] describes procedures that upper- 560 layer protocols can execute to verify that the above-mentioned 561 requirements are satisfied. Upper-layer protocols can execute these 562 procedures before emitting packets that contain the Truncation 563 Eligible option. 565 12. Encapsulating Security Payload Considerations 567 An IPv6 packet can contain both: 569 o An Encapsulating Security Payload (ESP) [RFC4303] header. 571 o Truncation options (i.e., the Truncation Eligible or Truncated 572 Packet options). 574 In this case, the packet MUST contain a Destination Options header 575 that precedes the ESP. That Destination Options header contains the 576 truncation options and is not protected by the ESP. The packet MAY 577 also contain another Destination Options header the follows the ESP. 578 That Destination Options header is protected by the ESP and MUST NOT 579 contain the truncation options. 581 As per RFC 4303, a packet can contain two Destination Options headers 582 one preceding the ESP and one following the ESP. 584 13. Extension Header Considerations 586 According to [RFC8200], the following IPv6 extension headers can 587 contain options: 589 o The Hop-by-hop Options header. 591 o The Destination Options header. 593 The Hop-by-hop option can be examined by each node along the path to 594 a packet's destination. Destination options are examined by the 595 destination node only. However, [RFC2473] provides a precedent for 596 intermediate nodes examining the Destination options on an exception 597 basis. (See the Tunnel Encapsulation Limit.) 599 The truncation options described herein are examined by: 601 o Intermediate nodes, on an exception basis (i.e, when the packet 602 cannot be forwarded due to MTU issues). 604 o The Destination node. 606 Therefore, the above-mentioned options can be processed most 607 efficiently when they are contained by the Destination Option header. 608 When contained by the Destination Options header, the above-mentioned 609 options are examined by intermediate nodes on an exception basis, 610 only when they are relevant. If contained by the Hop-by-hop Options 611 header, they are always examined by intermediate nodes, even when 612 they are irrelevant. 614 14. Security Considerations 616 PMTUD is vulnerable to ICMP PTB forgery attacks. The procedures 617 described herein do nothing to mitigate that vulnerability. 619 The procedures described herein are susceptible to a new variation on 620 that attack, in which an attacker forges a truncated packet. In this 621 case, the attackers cause the Destination Node to produce an ICMP PTB 622 message on their behalf. To some degree, this vulnerability is 623 mitigated, because the Destination Node will not emit an ICMP PTB 624 message in response to a truncated packet whose length is less than 625 the IPv6 minimum link MTU. 627 In order to mitigate denial of service attacks, intermediate nodes 628 MUST rate limit the number of packets that they truncate per second. 630 15. IANA Considerations 632 IANA is requested to allocate the following codepoints from the 633 Destination Options and Hop-by-hop Options registry 634 (https://www.iana.org/assignments/ipv6-parameters/ 635 ipv6-parameters.xhtml#ipv6-parameters-2). 637 o Truncation Eligible ("act-bits" are "00. "chg-bit" can be either 0 638 or 1.) 640 o Truncated Packet ("act-bits" are "10". "chg-but can be either 0 or 641 1.) 643 16. Acknowledgements 645 Special thanks to Mike Heard, Geoff Huston, Joel Jaeggli, Tom Jones, 646 Andy Smith, Jinmei Tatuya, and Reji Thomas who reviewed and commented 647 on this document. 649 17. References 651 17.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 659 RFC 4303, DOI 10.17487/RFC4303, December 2005, 660 . 662 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 663 Control Message Protocol (ICMPv6) for the Internet 664 Protocol Version 6 (IPv6) Specification", STD 89, 665 RFC 4443, DOI 10.17487/RFC4443, March 2006, 666 . 668 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 669 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 670 May 2017, . 672 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 673 (IPv6) Specification", STD 86, RFC 8200, 674 DOI 10.17487/RFC8200, July 2017, 675 . 677 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 678 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 679 DOI 10.17487/RFC8201, July 2017, 680 . 682 17.2. Informative References 684 [I-D.bonica-6man-unrecognized-opt] 685 Bonica, R. and J. Leddy, "The IPv6 Probe Option", draft- 686 bonica-6man-unrecognized-opt-03 (work in progress), August 687 2018. 689 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 690 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 691 December 1998, . 693 [RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of 694 the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too 695 Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, 696 . 698 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 699 "Observations on the Dropping of Packets with IPv6 700 Extension Headers in the Real World", RFC 7872, 701 DOI 10.17487/RFC7872, June 2016, 702 . 704 Authors' Addresses 706 John Leddy 707 Unaffiliated 709 Email: john@leddy.net 710 Ron Bonica 711 Juniper Networks 712 2251 Corporate Park Drive 713 Herndon, Virginia 20171 714 USA 716 Email: rbonica@juniper.net 718 Igor Lubashev 719 Akamai Technologies 720 Cambridge, MA 721 USA 723 Email: ilubashe@akamai.com