idnits 2.17.1 draft-leddy-6man-truncate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 11 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 (June 11, 2018) is 2145 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) == Unused Reference: 'RFC4291' is defined on line 596, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-bonica-6man-unrecognized-opt-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man J. Leddy 3 Internet-Draft Comcast 4 Intended status: Standards Track R. Bonica 5 Expires: December 13, 2018 Juniper Networks 6 June 11, 2018 8 Destination Originates Internet Control Message Protocol (ICMP) Packet 9 Too Big (PTB) Messages 10 draft-leddy-6man-truncate-03 12 Abstract 14 This document defines procedures that enhance Path MTU Discovery 15 (PMTUD), so that it no longer relies on the network's ability to 16 deliver an ICMP Packet Too Big (PTB) message from a downstream router 17 to an IPv6 source node. According to these procedures, selected 18 packets carry a new IPv6 Destination option. When a downstream 19 router cannot forward one of these packets because of MTU issues, it 20 truncates the packet, marks it to indicate that it has been 21 truncated, and forwards it towards the destination node. 23 When the destination node receives a packet that has been truncated, 24 it sends an ICMP PTB message to the source node. The source node 25 uses MTU information contained by the ICMP PTB message to update its 26 PMTU estimate. 28 The destination node also examines the new Destination option to 29 determine whether it should discard the truncated packet or deliver 30 it to an upper-layer protocol. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 13, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 68 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 69 4. Reference Topology . . . . . . . . . . . . . . . . . . . . . 5 70 5. Truncation Option . . . . . . . . . . . . . . . . . . . . . . 6 71 6. PMTU Signaling Procedures . . . . . . . . . . . . . . . . . . 7 72 7. Truncation Considerations . . . . . . . . . . . . . . . . . . 8 73 8. ICMP Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 9. Delivering Truncated Packets . . . . . . . . . . . . . . . . 9 75 10. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 76 11. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 11 77 12. Upper-Layer Considerations . . . . . . . . . . . . . . . . . 11 78 13. Encapsulating Security Payload Considerations . . . . . . . . 11 79 14. Extension Header Considerations . . . . . . . . . . . . . . . 12 80 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 83 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 18.1. Normative References . . . . . . . . . . . . . . . . . . 13 85 18.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 An Internet path connects a source node to a destination node. A 91 path can contain links and routers. 93 Each link is constrained by the number of bytes that it can convey in 94 a single IP packet. This constraint is called the link Maximum 95 Transmission Unit (MTU). IPv6 [RFC8200] requires every link to have 96 an MTU of 1280 bytes or greater. This value is called IPv6 minimum 97 link MTU. 99 Likewise, each Internet path is constrained by the number of bytes 100 that it can convey in a IP single packet. This constraint is called 101 the Path MTU (PMTU). For any given path, the PMTU is equal to the 102 smallest of its link MTUs. 104 IPv6 allows fragmentation at the source node only. If an IPv6 source 105 node sends a packet whose length exceeds the destination PMTU, the 106 packet will be discarded. In order to avoid this kind of packet 107 loss, IPv6 nodes can either: 109 o Refrain from sending packets whose length exceeds the IPv6 minimum 110 link MTU. 112 o Maintain a running estimate of the destination PMTU and refrain 113 from sending packets whose length exceeds that estimate. 115 IPv6 nodes can execute Path MTU Discovery (PMTUD) [RFC8201] 116 procedures in order to maintain a running estimate of the destination 117 PMTU. According to these procedures, the source node produces an 118 initial PMTU estimate. This initial estimate is equal to the MTU of 119 the first link along the path to the destination node. It can be 120 greater than the actual PMTU. 122 Having produced an initial PMTU estimate, the source node sends 123 packets to the destination node. If one of these packets is larger 124 than the actual PMTU, a downstream router will not be able to forward 125 the packet through the next link along the path. Therefore, the 126 downstream router discards the packet and sends an Internet Control 127 Message Protocol (ICMP) [RFC4443] Packet Too Big (PTB) message to the 128 source node. The ICMP PTB message indicates the MTU of the link 129 through which the packet could not be forwarded. The source node 130 uses this information to refine its PMTU estimate. 132 PMTUD relies on the network's ability to deliver ICMP PTB messages 133 from the downstream router to the source node. If the network cannot 134 deliver these messages, a persistent black hole can develop. In this 135 scenario, the source node sends a packet whose length exceeds the 136 destination PMTU. A downstream router discards the packet and sends 137 an ICMP PTB message to the source. However, the network cannot 138 deliver the ICMP PTB message to the source. Therefore, the source 139 node does not update its PMTU estimate and it continues to send 140 packets whose length exceeds the destination PMTU. The downstream 141 router discards these packets and sends ICMP PTB messages to the 142 source. These ICMP PTB messages are lost, exactly as previous ICMP 143 PTB messages were lost. 145 In some operational scenarios (Section 3), networks cannot deliver 146 ICMP PTB messages from a downstream router to the source node. 147 Therefore, enhanced procedures are required. 149 This document defines procedures that enhance PMTUD, so that it no 150 longer relies on the network's ability to deliver an ICMP PTB message 151 from a downstream router to an IPv6 source node. According to these 152 procedures, selected packets carry a new IPv6 Destination option. 153 When a downstream router cannot forward one of these packets because 154 of MTU issues, it truncates the packet, marks it to indicate that it 155 has been truncated, and forwards it towards the destination node. 157 When the destination node receives a packet that has been truncated, 158 it sends an ICMP PTB message to the source node. The source node 159 uses MTU information contained by the ICMP PTB message to update its 160 PMTU estimate. 162 The destination node also examines the new Destination option to 163 determine whether it should discard the truncated packet or deliver 164 it to an upper-layer protocol. If the truncated packet is delivered 165 to an upper-layer protocol, the upper-layer protocol can infer the 166 PMTU between the source node and itself from the packet's length. 167 Having inferred the PMTU, the upper-layer protocol can negotiate a 168 maximum packet size with its upper-layer peer, thus reducing its 169 dependence upon PMTUD and IPv6 fragmentation. 171 While packet truncation may facilitate new upper-layer procedures, 172 upper-layer procedures are beyond the scope of this document. 174 2. Requirements Language 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in BCP 179 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 3. Operational Considerations 184 The packet truncation procedures described herein make PMTUD more 185 resilient when: 187 o The network can deliver ICMP PTB messages from the destination 188 node to the source node. 190 o The network cannot deliver ICMP PTB messages from a downstream 191 router to the source node. 193 The following are operational scenarios in which packet truncation 194 procedures can make PMTUD more resilient: 196 o The destination node has a viable route to the source node, but 197 the downstream router does not. 199 o The source node is protected by a firewall that administratively 200 blocks all packets except for those from specified subnetworks. 201 The destination node resides in one of the specified subnetworks, 202 but the downstream router does not. 204 o The source address of the original packet (i.e., the packet that 205 elicited the ICMP PTB message) was an anycast address. Therefore, 206 the destination address of the ICMP PTB message is the same 207 anycast address. In this case, an ICMP PTB message from the 208 destination node is likely to be delivered to the correct anycast 209 instance. By contrast, an ICMP PTB message from a downstream 210 router is less likely to be delivered to the correct anycast 211 instance. 213 Packet truncation procedures do not make PMTUD more resilient when 214 the network cannot reliably deliver any ICMP PTB messages to the 215 source node. The following are operational scenarios where the 216 network cannot reliably deliver any ICMP PTB messages to the source 217 node: 219 o The source node is protected by a firewall that administratively 220 blocks all ICMP PTB messages. 222 o The source node is an anycast instance served by a load-balancer 223 as defined in [RFC7690]. The load-balancer does not implement the 224 mitigations defined in [RFC7690]. 226 4. Reference Topology 228 ------------- ------------- ------------- 229 | Upper | | | | Upper | 230 | Layer | | | | Layer | 231 | | | | | | 232 | IP |<-------->| IP |<-------->| IP | 233 | Layer | MTU | Layer | MTU | Layer | 234 ------------- 9000 ------------- 1500 ------------- 235 Source Router Destination 236 Node Node 238 Figure 1 240 Figure 1 depicts a reference topology that is used in this document. 241 The reference topology includes a source node, a router, and a 242 destination node. The link that connects the source node to the 243 router has an MTU of 9000 bytes. The link that connects the router 244 to the destination node has an MTU of 1500 bytes. Therefore, the 245 PMTU between the source node and the destination node is 1500 bytes. 247 5. Truncation Option 249 0 1 2 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Option Type | Opt Data Len |T|D|R| Reserved| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2 257 Figure 2 depicts the Truncation option. The IPv6 Destination Options 258 header MAY include the Truncation option. The IPv6 Hop-by-hop header 259 MUST NOT include the Truncation option. 261 o Option Type - Truncation option. Value TBD by IANA. See Notes 262 below. 264 o Opt Data Len - Length of Option Data, measured in bytes. MUST be 265 equal to 1. 267 o T - Indicates that the packet has been truncated. If the packet 268 has not been truncated, it SHOULD be delivered to an upper-layer 269 protocol. 271 o D - Indicates that the packet SHOULD be delivered to an upper- 272 layer protocol even if it has been truncated. If the D-bit is set 273 to zero, the packet MUST NOT be delivered to an upper-layer 274 protocol if it has been truncated. 276 o R - Request to deliver truncated packets. 278 A packet MUST NOT contain multiple instances of the Truncation 279 option. If a node receives a packet that contains multiple instances 280 of the Truncation option, it processes the first instance and ignores 281 all subsequent instances. 283 NOTE 1: The highest-order two bits of the Option Type (i.e., the 284 "act" bits) are 10. These bits specify the action taken by a 285 destination node that does not recognize Truncation option. The 286 required action is to discard the packet and, regardless of whether 287 or not the packet's Destination Address was a multicast address, send 288 an ICMP Parameter Problem, Code 2, message to the packet's Source 289 Address, pointing to the unrecognized Option Type. 291 NOTE 2: The third highest-order bit of the Option Type (i.e., the 292 "chg" bit) is 1. This indicates that Option Data can be modified 293 along the path between the packet's source and its destination. 295 6. PMTU Signaling Procedures 297 In the Reference Topology (Figure 1), the upper-layer protocol that 298 resides on the source node submits a packet to its local IP layer. 299 The packet includes a Truncation option (Section 5). Within the 300 Truncation option: 302 o The T-bit is set to zero, indicating that the packet has not been 303 truncated. 305 o The D-bit is set to zero, indicating that the packet MUST NOT be 306 delivered to an upper-layer protocol if the packet has been 307 truncated. 309 o The R-bit is set to zero, indicating that the source node does not 310 request delivery of truncated packets 312 The packet length is 500 bytes. Because the packet length is less 313 than the destination PMTU, the packet can be delivered without 314 encountering MTU issues. 316 The IP layer on the source node forwards the packet to the downstream 317 router and the downstream router forwards the packet to the 318 destination node. The IP layer on the destination node examines the 319 Destination Option header. Because it recognizes the Truncation 320 option, and because the packet has not been truncated, it delivers 321 the packet to an upper-layer protocol. 323 Now, the upper-layer protocol that resides on the source node submits 324 another packet to its local IP layer. This packet is identical to 325 the first, except that the packet length is 2000 bytes. Because the 326 packet length is greater than the destination PMTU, the packet cannot 327 be delivered without encountering MTU issues. 329 The IP layer on the source node forwards the packet to the downstream 330 router but the downstream router cannot forward the packet because 331 its length exceeds the MTU of the next-hop link. Because an MTU 332 issue has been encountered, the IP Layer on the downstream router 333 examines the Destination Options header, searching for a Truncation 334 option. (Normally, the downstream router would ignore the 335 Destination Options header). 337 Because the downstream router finds and recognizes the Truncation 338 option, it: 340 o Truncates the packet, so that its new length equals the MTU of the 341 next-hop link. 343 o Updates the Payload Length field in the IPv6 header as 344 appropriate. 346 o Sets the T-bit in the Truncation option. 348 o Forwards the packet to the destination node. 350 The IP layer on the destination node examines the Destination Option 351 header. Because it recognizes the Truncation option, and because the 352 packet has been truncated, it sends an ICMP PTB message to the source 353 node. The MTU field in the ICMP PTB message is set to the packet's 354 length. 356 The IP layer on the destination node then discards the packet because 357 the packet has been truncated and the D-bit is set to 0. It does not 358 deliver the packet to an upper-layer protocol. 360 As per [RFC8201], the source node updates its PMTU estimate using 361 information contained by the ICMP PTB message. 363 7. Truncation Considerations 365 A packet can be truncated multiple times. 367 ------------- ------------- ------------- ------------- 368 | IP |<-------->| IP |<-------->| IP |<-------->| IP | 369 | Layer | MTU | Layer | MTU | Layer | MTU | Layer | 370 ------------- 9000 ------------- 4000 ------------- 1500 ------------- 371 Source Router1 Router 2 Destination 372 Node Node 374 Figure 3: Double Truncation 376 Figure 3 depicts a network that contains a Source Node, Router1, 377 Router2 and a Destination Node. The link that connects the Source 378 Node to Router1 has an MTU of 9000 bytes. The link that connects 379 Router1 to Router2 has an MTU of 4000 bytes, and the link that 380 connects Router2 to the Destination Node has an MTU of 1500 bytes. 382 Assume that the Source Node sends a packet to the Destination Node. 383 The packet is 8000 bytes long. When Router1 receives this packet, it 384 identifies the next-hop towards the destination. This is the link 385 that connects Router1 to Router2. Router 1 encounters an MTU issue, 386 because the packet length (8000 bytes) is greater than the MTU 387 associated with the next-hop link (4000 bytes). Therefore, Router 1 388 truncates the packet to 4000 bytes, sets the T-bit in the Truncation 389 Option, and forwards the packet towards Router2. When Router2 390 receives this packet, it identifies the next-hop towards the 391 destination. This is the link that connects Router2 to the 392 Destination Node. Router 2 encounters an MTU issue, because the 393 packet length (4000 bytes) is greater than the MTU associated with 394 the next-hop link (1500 bytes). Therefore, Router 2 truncates the 395 packet to 1500 bytes, sets the T-bit in the Truncation Option, and 396 forwards the packet towards the Destination Node. The Destination 397 Node sends an ICMP PTB packet to the source node. The MTU field in 398 the ICMP PTB field is set to 1500. 400 A truncated packet MUST contain the basic IPv6 header, all extension 401 headers and the first upper-layer header. When a router cannot 402 forward a packet through the next-hop link due to MTU issues, and the 403 total length of the basic IPv6 header, all extension headers, and 404 first upper-layer header exceeds the MTU of the next-hop link, the 405 router MUST discard the packet and send and ICMP PTB message to the 406 source. 408 Source nodes MUST NOT emit packets that contain both the Fragment 409 Header and Truncation Option. 411 Routers MUST NOT truncate packets that include the Fragment header. 412 When a router cannot forward a packet through the next-hop link due 413 to MTU issues, and the packet includes a Fragment header, the router 414 MUST discard the packet and send and ICMP PTB message to the source. 416 Routers MUST NOT emit truncated packets whose length is less than the 417 IPv6 minimum link MTU. 419 8. ICMP Considerations 421 When a destination node receives a truncated packet whose length is 422 less than the IPv6 minimum link MTU, the destination node MUST 423 discard the packet. It MUST NOT send an ICMP PTB message to the 424 packet's source and it MUST NOT deliver the packet to an upper-layer 425 protocol. 427 9. Delivering Truncated Packets 429 A destination node MUST NOT deliver a truncated packet to an upper- 430 layer protocol if the D-bit is set to zero. However, a destination 431 node SHOULD deliver a truncated packet to an upper-layer protocol if 432 the D-bit is set to one. 434 The upper-layer protocol on the source node determines the D-bit 435 value. The following are possible behaviors: 437 o Some upper-layer protocols never set the D-bit. 439 o Some upper-layer protocols always set the D-bit. 441 o Some upper-layer protocols only set the D-bit when requested to do 442 so by the upper-layer protocol on the destination node. These 443 upper-layer protocols interpret the receipt of a Truncation option 444 with the R-bit set as a request to set the D-bit on all subsequent 445 packets. 447 10. Backward Compatibility 449 The procedures described in Section 6 of this document assume that 450 the source node, downstream router and destination node all 451 recognized the Truncation option. This section explores backwards 452 compatibility, where one or more nodes do not recognize the 453 Truncation option. 455 If the destination node does not recognize the Truncation option, and 456 it receives a packet that includes the Truncation option, it discards 457 the packet and, regardless of whether or not the packet's Destination 458 Address was a multicast address, sends an ICMP Parameter Problem, 459 Code 2, message to the packet's Source Address, pointing to the 460 unrecognized Option Type. This behavior is determined by the 461 highest-order two bytes of the Option Type. When the source node 462 receives the ICMP Parameter Problem message, it refrains from sending 463 packets that contain the Truncation option. 465 If the downstream router does not recognize the Truncation option and 466 it receives a packet that contains the Truncation option and that 467 packets length does not exceed the next-hop MTU, the downstream 468 router forwards the packet, without examining the Truncation option 469 or any other Destination option. If the downstream router does not 470 recognize the Truncation option and it receives a packet that 471 contains the Truncation option and that packets length exceeds the 472 next-hop MTU, the downstream discards the packet and sends an ICMP 473 PTB message to the source node, as per [RFC8200]. 475 In all cases mentioned above, PMTUD continues to function as 476 specified in [RFC8201]. 478 11. Optimizations 480 The procedures described in Section 6 of this document can be 481 optimized by omitting the Truncation option on packets whose length 482 is known to be less than the destination PMTU (e.g., packets whose 483 length is less than the IPv6 minimum link MTU). 485 12. Upper-Layer Considerations 487 The procedures described herein rely upon: 489 o The network's ability to convey packets that contain destination 490 options from a source node to a destination node. 492 o The network's ability to convey ICMP Parameter Problem messages in 493 the reverse direction. 495 Operational experience [RFC7872] reveals that a significant number of 496 networks drop packets that contain IPv6 destination options. 497 Likewise, many networks drop ICMP Parameter Problem messages. 499 [I-D.bonica-6man-unrecognized-opt] describes procedures that upper- 500 layer protocols can execute to verify that the above-mentioned 501 requirements are satisfied. Upper-layer protocols can execute these 502 procedures before emitting packets that contain the Truncation 503 option. 505 13. Encapsulating Security Payload Considerations 507 An IPv6 packet can contain both: 509 o An Encapsulating Security Payload (ESP) [RFC4303] header. 511 o The Truncation Option. 513 In this case, the packet MUST contain a Destination Options header 514 that precedes the ESP. That Destination Options header contains the 515 Truncation Option and is not protected by the ESP. The packet MAY 516 also contain another Destination Options header the follows the ESP. 517 This Destination Options header is protected by the ESP and MUST NOT 518 contain the Truncation Option. 520 As per RFC 4303, a packet can contain two Destination Option headers 521 one preceding the ESP and one following the ESP. 523 14. Extension Header Considerations 525 According to [RFC8201], the following IPv6 extension headers can 526 carry options: 528 o The Hop-by-hop Options header. 530 o The Destination Options header. 532 The Hop-by-hop Options header is examined by the destination node. 533 It can also be examined by intermediate nodes (i.e., nodes along the 534 path between the source and the destination), so long as those nodes 535 are configured to process Hop-by-hop options. By contrast, the 536 Destination Options header is examined by the destination node only. 538 The Truncation option is examined by: 540 o The destination node. 542 o Intermediate nodes, but only on an exception basis (i.e., when the 543 intermediate node cannot forward the packet due to MTU issues) 545 If performance were not a concern, the Hop-by-hop Options header 546 could carry the Truncation Option. The destination node would 547 examine the Truncation option, as would every intermediate node. 548 However, the performance impact would not be acceptable. 550 By contrast, the Destination Option can carry the truncation option, 551 so long as intermediate nodes can examine the Destination Option 552 header on an exception basis (e.g., when the packet cannot be 553 forwarded due to MTU issues). [RFC2473] sets a precedent for 554 intermediate nodes examining the Destination Options header on an 555 exception basis. (See the Tunnel Encapsulation Limit.) 557 Therefore, The IPv6 Destination Options header MAY include the 558 Truncation option and the IPv6 Hop-by-hop header MUST NOT include the 559 Truncation option. 561 15. Security Considerations 563 PMTUD is vulnerable to ICMP PTB forgery attacks. The procedures 564 described herein do nothing to mitigate that vulnerability. 566 The procedures described herein are susceptible to a new variation on 567 that attack, in which an attacker forges a truncated packet. In this 568 case, the attackers cause the destination node to produce an ICMP PTB 569 message on their behalf. To some degree, this vulnerability is 570 mitigated, because the destination node will not emit an ICMP PTB 571 message in response to a truncated packet whose length is less than 572 the IPv6 minimum link MTU. 574 16. IANA Considerations 576 IANA is requested to allocate a codepoint from the Destination 577 Options and Hop-by-hop Options registry 578 (https://www.iana.org/assignments/ipv6-parameters/ 579 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 580 "Truncation". The "act" bits are 10 and the "chg" bit is 1. 582 17. Acknowledgements 584 Special thanks to Mike Heard, Geoff Huston, Joel Jaegglii, Andy 585 Smith, and Jinmei Tatuya who reviewed and commented on this document. 587 18. References 589 18.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, 593 DOI 10.17487/RFC2119, March 1997, 594 . 596 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 597 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 598 2006, . 600 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 601 RFC 4303, DOI 10.17487/RFC4303, December 2005, 602 . 604 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 605 Control Message Protocol (ICMPv6) for the Internet 606 Protocol Version 6 (IPv6) Specification", STD 89, 607 RFC 4443, DOI 10.17487/RFC4443, March 2006, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 615 (IPv6) Specification", STD 86, RFC 8200, 616 DOI 10.17487/RFC8200, July 2017, 617 . 619 [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., 620 "Path MTU Discovery for IP version 6", STD 87, RFC 8201, 621 DOI 10.17487/RFC8201, July 2017, 622 . 624 18.2. Informative References 626 [I-D.bonica-6man-unrecognized-opt] 627 Bonica, R. and J. Leddy, "The IPv6 Unrecognized Option", 628 draft-bonica-6man-unrecognized-opt-00 (work in progress), 629 June 2018. 631 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 632 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 633 December 1998, . 635 [RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of 636 the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too 637 Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, 638 . 640 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 641 "Observations on the Dropping of Packets with IPv6 642 Extension Headers in the Real World", RFC 7872, 643 DOI 10.17487/RFC7872, June 2016, 644 . 646 Authors' Addresses 648 John Leddy 649 Comcast 650 1717 John F Kennedy Blvd. 651 Philadelphia, PA 19103 652 USA 654 Email: john_leddy@comcast.com 656 Ron Bonica 657 Juniper Networks 658 2251 Corporate Park Drive 659 Herndon, Virginia 20171 660 USA 662 Email: rbonica@juniper.net