idnits 2.17.1 draft-leddy-6man-truncate-04.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 (June 29, 2018) is 2127 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-bonica-6man-unrecognized-opt-01 Summary: 1 error (**), 0 flaws (~~), 2 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 31, 2018 Juniper Networks 6 June 29, 2018 8 IPv6 Packet Truncation 9 draft-leddy-6man-truncate-04 11 Abstract 13 This document defines IPv6 packet truncation procedures. When an 14 IPv6 source node originates a packet, it can mark the packet as being 15 eligible for truncation and forward it towards its destination. If 16 an intermediate node cannot forward the packet because of an MTU 17 issue, it truncates the packet, marks it as being truncated, and, 18 again, forwards it towards its destination. When the destination 19 node receives the packet, it detects that it has been truncated and 20 sends an ICMP message to the source node. The ICMP message contains 21 MTU information that the source node uses to update its Path MTU 22 estimate. 24 The above-mentioned procedures enhance Path MTU Discovery (PMTUD) by 25 eliminating its reliance on the network's ability to deliver ICMP 26 messages from an intermediate node to the source node. However, the 27 above-mentioned procedures require the network to deliver ICMP 28 messages from the destination node to the source node. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 31, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 66 3. Operational Considerations . . . . . . . . . . . . . . . . . 5 67 4. Reference Topology . . . . . . . . . . . . . . . . . . . . . 5 68 5. New IPv6 Destination Options . . . . . . . . . . . . . . . . 6 69 5.1. The IPv6 Truncation Eligible Option . . . . . . . . . . . 6 70 5.2. The IPv6 Truncated Packet Option . . . . . . . . . . . . 7 71 6. PMTU Signaling Procedures . . . . . . . . . . . . . . . . . . 8 72 7. Truncation Considerations . . . . . . . . . . . . . . . . . . 9 73 8. Destination Node Considerations . . . . . . . . . . . . . . . 10 74 9. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 75 10. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 11 76 11. Upper-Layer Considerations . . . . . . . . . . . . . . . . . 11 77 12. Encapsulating Security Payload Considerations . . . . . . . . 11 78 13. Extension Header Considerations . . . . . . . . . . . . . . . 12 79 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 82 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 17.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 17.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 An Internet path connects a source node to a destination node. A 90 path can contain links and intermediate nodes (e.g., routers). 92 Each link is constrained by the number of bytes that it can convey in 93 a single IP packet. This constraint is called the link Maximum 94 Transmission Unit (MTU). IPv6 [RFC8200] requires every link to have 95 an MTU of 1280 bytes or greater. This value is called IPv6 minimum 96 link MTU. 98 Likewise, each Internet path is constrained by the number of bytes 99 that it can convey in a IP single packet. This constraint is called 100 the Path MTU (PMTU). For any given path, the PMTU is equal to the 101 smallest of its link MTUs. 103 IPv6 allows fragmentation at the source node only. If an IPv6 source 104 node sends a packet whose length exceeds the PMTU, an intermediate 105 node will discard the packet. In order to prevent this, IPv6 nodes 106 can either: 108 o Refrain from sending packets whose length exceeds the IPv6 minimum 109 link MTU. 111 o Maintain a running estimate of the PMTU and refrain from sending 112 packets whose length exceeds that estimate. 114 IPv6 nodes can execute Path MTU Discovery (PMTUD) [RFC8201] 115 procedures in order to maintain a running estimate of the PMTU. 116 According to these procedures, the source node produces an initial 117 PMTU estimate. This initial estimate is equal to the MTU of the 118 first link along the path to the destination. It can be greater than 119 the actual PMTU. 121 Having produced an initial PMTU estimate, the source node sends 122 packets to the destination node. If one of these packets is larger 123 than the actual PMTU, an intermediate node will not be able to 124 forward the packet through the next link along the path. Therefore, 125 the intermediate node discards the packet and sends an Internet 126 Control Message Protocol (ICMP) [RFC4443] Packet Too Big (PTB) 127 message to the source node. The ICMP PTB message indicates the MTU 128 of the link through which the packet could not be forwarded. The 129 source node uses this information to refine its PMTU estimate. 131 PMTUD relies on the network's ability to deliver ICMP PTB messages 132 from the intermediate node to the source node. If the network cannot 133 deliver these messages, a persistent black hole can develop. In this 134 scenario, the source node sends a packet whose length exceeds the 135 PMTU. An intermediate node discards the packet and sends an ICMP PTB 136 message to the source. However, the network cannot deliver the ICMP 137 PTB message to the source. Therefore, the source node does not 138 update its PMTU estimate and it continues to send packets whose 139 length exceeds the PMTU. The intermediate node discards these 140 packets and sends more ICMP PTB messages to the source. These ICMP 141 PTB messages are lost, exactly as previous ICMP PTB messages were 142 lost. 144 In some operational scenarios (Section 3), networks cannot deliver 145 ICMP PTB messages from an intermediate node to the source node. 146 Therefore, enhanced procedures are required. 148 This document defines IPv6 packet truncation procedures. When an 149 IPv6 source node originates a packet, it can mark the packet as being 150 eligible for truncation and forward it towards its destination. If 151 an intermediate node cannot forward the packet because of an MTU 152 issue, it truncates the packet, marks it as being truncated, and, 153 again, forwards it towards its destination. When the destination 154 node receives the packet, it detects that it has been truncated and 155 sends an ICMP message to the source node. The ICMP message contains 156 MTU information that the source node uses to update its Path MTU 157 estimate. 159 The above-mentioned procedures enhance PMTUD by eliminating its 160 reliance on the network's ability to deliver ICMP messages from an 161 intermediate node to the source node. However, the above-mentioned 162 procedures require the network to deliver ICMP messages from the 163 destination node to the source node. 165 By default, destination nodes discard truncated packets and do not 166 deliver them to upper-layer protocols. However, upper-layer 167 protocols can register for delivery of truncated packets. When an 168 upper-layer protocol receives a truncated packet, it can infer the 169 PMTU between the source node and itself from the packet's length. 170 Having inferred the PMTU, the upper-layer protocol can negotiate a 171 maximum packet size with its upper-layer peer, thus reducing its 172 reliance upon PMTUD and IPv6 fragmentation. 174 While IPv6 packet truncation may facilitate new upper-layer 175 procedures, upper-layer procedures are beyond the scope of this 176 document. In particular, this document does not address the behavior 177 of upper-layer protocols that register for delivery of truncated 178 packets. 180 2. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119] [RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 3. Operational Considerations 190 The packet truncation procedures described herein make PMTUD more 191 resilient when: 193 o The network can deliver ICMP messages from the destination node to 194 the source node. 196 o The network cannot deliver ICMP messages from an intermediate node 197 to the source node. 199 The following are operational scenarios in which packet truncation 200 procedures can make PMTUD more resilient: 202 o The destination node has a viable route to the source node, but 203 the intermediate node does not. 205 o The source node is protected by a firewall that administratively 206 blocks all packets except for those from specified subnetworks. 207 The destination node resides in one of the specified subnetworks, 208 but the intermediate node does not. 210 o The source address of the original packet (i.e., the packet that 211 elicited the ICMP message) was an anycast address. Therefore, the 212 destination address of the ICMP message is the same anycast 213 address. In this case, an ICMP message from the destination node 214 is likely to be delivered to the correct anycast instance. By 215 contrast, an ICMP message from an intermediate node is less likely 216 to be delivered to the correct anycast instance. 218 Packet truncation procedures do not make PMTUD more resilient when 219 the network cannot reliably deliver any ICMP messages to the source 220 node. The following are operational scenarios where the network 221 cannot reliably deliver any ICMP PTB messages to the source node: 223 o The source node is protected by a firewall that administratively 224 blocks all ICMP messages. 226 o The source node is an anycast instance served by a load-balancer 227 as defined in [RFC7690]. The load-balancer does not implement the 228 mitigations defined in [RFC7690]. 230 4. Reference Topology 231 ----------- ----------- ----------- ----------- 232 | Upper | | | | | | Upper | 233 | Layer | | | | | | Layer | 234 | | | | | | | | 235 | IP |<-------->| IP |<-------->| IP |<-------->| IP | 236 | Layer | MTU | Layer | MTU | Layer | MTU | Layer | 237 ----------- 9000 ----------- 4000 ----------- 1500 ----------- 238 Source Router 1 Router 2 Destination 239 Node Node 241 Figure 1: Reference Topology 243 Figure 1 depicts a network that contains a Source Node, intermediate 244 nodes (i.e., Router 1, Router 2), and a Destination Node. The link 245 that connects the Source Node to Router 1 has an MTU of 9000 bytes. 246 The link that connects Router 1 to Router 2 has an MTU of 4000 bytes, 247 and the link that connects Router 2 to the Destination Node has an 248 MTU of 1500 bytes. The PMTU between the Source Node and the 249 Destination Node is 1500 bytes. 251 This topology will be used in examples throughout the document. 253 5. New IPv6 Destination Options 255 This document defines the IPv6 Truncation Eligible option and the 256 IPv6 Truncated Packet option. 258 5.1. The IPv6 Truncation Eligible Option 260 The IPv6 Truncation Eligible Option indicates that the packet is 261 eligible for truncation but has not been truncated. It contains the 262 following fields: 264 o Option Type - Truncation Eligible option. Value TBD by IANA. See 265 Notes below. 267 o Opt Data Len - Length of Option Data, measured in bytes. MUST be 268 equal to 0. 270 The IPv6 Destination Options header: 272 o MAY include a single instance of the Truncation Eligible option. 274 o SHOULD NOT include multiple instances of the Truncation Eligible 275 option. 277 o SHOULD NOT include both the Truncation Eligible option and the 278 Truncated Packet option. 280 The IPv6 Hop-by-hop Options header SHOULD NOT include the Truncation 281 Eligible option. 283 Source nodes MUST NOT emit packets that contain both the Fragment 284 Header and Truncation Eligible option. 286 NOTE 1: According to [RFC8200], the highest-order two bits of the 287 Option Type (i.e., the "act" bits) specify the action taken by a 288 destination node that does not recognize Option Type. The required 289 action is skip over this option and continue processing the header. 290 Therefore, IANA is requested to assign this Option Type with "act" 291 bits "00". 293 NOTE 2: According to [RFC8200], the third-highest-order bit (i.e., 294 the "chg" bit) of the Option Type specifies whether or not the Option 295 Data of that option can change en route to the packet's final 296 destination. Because this option contains no Option Data, IANA can 297 assign this Option Type without regard to the "chg" bit. 299 5.2. The IPv6 Truncated Packet Option 301 The IPv6 Truncated Packet Option indicates that the packet has been 302 truncated and is eligible for further truncation. It contains the 303 following fields: 305 o Option Type - Truncated Packet option. Value TBD by IANA. See 306 Notes below. 308 o Opt Data Len - Length of Option Data, measured in bytes. MUST be 309 equal to 0. 311 The IPv6 Destination Options: 313 o MAY include a single instance of the Truncated Packet option. 315 o SHOULD NOT include multiple instances of the Truncated Packet 316 option. 318 o SHOULD NOT include both the Truncated Packet option and the 319 Truncation Eligible option. 321 The IPv6 Hop-by-hop Options header SHOULD NOT include the Truncated 322 Packet option. 324 Source nodes MUST NOT emit packets that contain both the Fragment 325 Header and Truncated Packet option. 327 NOTE 1: According to [RFC8200], the highest-order two bits of the 328 Option Type (i.e., the "act" bits) specify the action taken by a 329 destination node that does not recognize Option Type. The required 330 action is to discard the packet and, regardless of whether or not the 331 packet's Destination Address was a multicast address, send an ICMP 332 Parameter Problem, Code 2, message to the packet's Source Address, 333 pointing to the unrecognized Option Type. Therefore, IANA is 334 requested to assign this Option Type with "act" bits "10". 336 NOTE 2: According to [RFC8200], the third-highest-order bit (i.e., 337 the "chg" bit) of the Option Type specifies whether or not the Option 338 Data of that option can change en route to the packet's final 339 destination. Because this option contains no Option Data, IANA can 340 assign this Option Type without regard to the "chg" bit. 342 6. PMTU Signaling Procedures 344 In the Reference Topology (Figure 1), an upper-layer protocol that 345 resides on the Source Node causes the IP layer to emit a packet. The 346 packet contains a Destination Options header and the Destination 347 Options header contains a Truncation Eligible option. The total 348 packet length, including all headers and the payload, is 1000 bytes. 349 Because the total packet length is less than the PMTU, the packet can 350 be delivered to the Destination Node without encountering any MTU 351 issues. 353 The IP layer on the Source Node forwards the packet to the Router 1, 354 Router 1 forwards the packet to Router 2, and the Router 2 forwards 355 the packet to the Destination Node. The IP layer on the Destination 356 Node examines the Destination Options header and finds the Truncation 357 Eligible option. The Truncation Eligible option requires no action 358 by the Destination Node. Therefore, the Destination Node processes 359 the next header and delivers the packet to an upper-layer protocol. 361 Subsequently, the upper-layer protocol that resides on the Source 362 Node causes the IP layer to emit another packet. This packet is 363 identical to the first, except that the total packet length is 2000 364 bytes. Because the packet length is greater than the PMTU, this 365 packet cannot be delivered without encountering an MTU issue. 367 The IP layer on the source node forwards the packet to Router 1. 368 Router 1 forwards the packet to Router 2, but the Router 2 cannot 369 forward the packet because its length exceeds the MTU of the next 370 link in the path. Because an MTU issue has been encountered, Router 371 2 examines the Destination Options header, searching for either a 372 Truncation Eligible option or a Truncated Packet option. (Normally, 373 the Router 2 would ignore the Destination Options header). 375 Because Router 2 finds one of the above-mentioned options, it: 377 o Truncates the packet, so that its total length equals the MTU of 378 the next link in the path. 380 o Updates the Payload Length field in the IPv6 header. 382 o Overwrites all instances of the Truncation Eligible option with a 383 Truncated Packet option. 385 o Forwards the packet to the Destination Node. 387 The IP layer on the Destination Node receives the packet and examines 388 the Destination Options header. Because it finds the Truncated 389 Packet option, it sends an ICMP PTB message to the Source Node. The 390 MTU field in the ICMP PTB message is set to the packet's length. 392 By default, the IP layer on the Destination Node discards the 393 truncated packet, without delivering it to any upper-layer protocol. 394 However, the upper-layer protocol can register for the delivery of 395 truncated packets. 397 When the Source Node receives the ICMP PTB message, it updates its 398 PMTU estimate, as per [RFC8201]. 400 7. Truncation Considerations 402 A packet can be truncated multiple times. In the Reference Topology 403 (Figure 1), assume that the Source Node sends a 5000 byte packet to 404 the Destination Node. Using the procedures described in Section 6, 405 Router 1 truncates this packet to 4000 bytes and Router 2 truncates 406 it again, to 1500 bytes. 408 A truncated packet MUST contain the basic IPv6 header, all extension 409 headers and the first upper-layer header. When an intermediate node 410 cannot forward a packet due to MTU issues, and the total length of 411 the basic IPv6 header, all extension headers, and first upper-layer 412 header exceeds the MTU of the next link in the path, the intermediate 413 node MUST discard the packet and send and ICMP PTB message to the 414 source node. It MUST NOT truncate the packet. 416 A truncated packet MUST NOT include the Fragment header. When an 417 intermediate node cannot forward a packet due to MTU issues, and the 418 packet contains a Fragment header, the intermediate node MUST discard 419 the packet and send and ICMP PTB message to the source node. It MUST 420 NOT truncate the packet. 422 A truncated packet must have a total length that is greater than or 423 equal to the IPv6 minimum link MTU. 425 8. Destination Node Considerations 427 The following packet types are invalid:: 429 o Packets that contain the Packet Truncated option and the Fragment 430 Header. 432 o Packets that contain the Packet Truncated option and have a total 433 length less than the IPv6 minimum link MTU. 435 When the destination node receives an invalid packet, it MUST: 437 o Discard the packet, without delivering it to any upper-layer 438 protocol, regardless of whether the upper-layer protocol has 439 registered for delivery of truncated packets. 441 o Send an ICMP Parameter Problem, Code 2, message to the packet's 442 Source Address, pointing to the Truncated Packet option. 444 9. Backward Compatibility 446 The procedures described in Section 6 assume that all nodes recognize 447 the Truncation Eligible option and Truncated Packet option. This 448 section explores backwards compatibility scenarios, where one or more 449 nodes do not recognize the above-mentioned options. 451 Assume that an intermediate node does not recognize the Truncation 452 Eligible option or the Truncated Packet option. When that node 453 receives a packet that it cannot forward because of an MTU issue, its 454 behavior is as described in [RFC8200]. The intermediate node 455 discards the packet and sends and ICMP PTB message to the source 456 node. It does not examine the Destination Options header, searching 457 for the above-mentioned options and it does not truncate the packet. 459 Now assume that a destination node does not recognize the Truncation 460 Eligible option. When that node receives a packet that contains the 461 Truncation Eligible option, its behavior is determined by the 462 highest-order two bits of the Option Type (i.e., the "act" bits). 463 Because the "act" bits are equal to "00", the destination node skips 464 over the option and continues to process the packet. This is exactly 465 what the destination node would have done if it had recognized the 466 Truncation Eligible option. 468 Finally, assume that a destination node does not recognize the 469 Truncated Packet option. When that node receives a packet that 470 contains the Truncated Packet option, its behavior is determined by 471 the highest-order two bits of the Option Type (i.e., the "act" bits). 472 Because the "act" bits are equal to "10", the destination node 473 discards the packet and, regardless of whether or not the packet's 474 Destination Address was a multicast address, send an ICMP Parameter 475 Problem, Code 2, message to the packet's Source Address, pointing to 476 the Truncated Packet option. The destination node does not emit an 477 ICMP PTB message and it does not deliver the packet to an upper-layer 478 protocol. 480 The source node takes appropriate action when it receives the ICMP 481 Parameter Problem message. 483 10. Optimizations 485 The procedures described in Section 6 of this document can be 486 optimized by omitting the Truncation Eligible option on packets whose 487 length is known to be less than the PMTU (e.g., packets whose length 488 is less than the IPv6 minimum link MTU). 490 11. Upper-Layer Considerations 492 The procedures described herein rely upon the networks ability: 494 o To convey packets that contain destination options from the source 495 node to the destination node. 497 o To convey ICMP Parameter Problem messages in the reverse 498 direction. 500 Operational experience [RFC7872] reveals that a significant number of 501 networks drop packets that contain IPv6 destination options. 502 Likewise, many networks drop ICMP Parameter Problem messages. 504 [I-D.bonica-6man-unrecognized-opt] describes procedures that upper- 505 layer protocols can execute to verify that the above-mentioned 506 requirements are satisfied. Upper-layer protocols can execute these 507 procedures before emitting packets that contain the Truncation 508 Eligible option. 510 12. Encapsulating Security Payload Considerations 512 An IPv6 packet can contain both: 514 o An Encapsulating Security Payload (ESP) [RFC4303] header. 516 o The Truncation Eligible Option. 518 In this case, the packet MUST contain a Destination Options header 519 that precedes the ESP. That Destination Options header contains the 520 Truncation Eligible Option and is not protected by the ESP. The 521 packet MAY also contain another Destination Options header the 522 follows the ESP. That Destination Options header is protected by the 523 ESP and MUST NOT contain the Truncation Eligible Option. 525 As per RFC 4303, a packet can contain two Destination Options headers 526 one preceding the ESP and one following the ESP. 528 13. Extension Header Considerations 530 According to [RFC8200], the following IPv6 extension headers can 531 contain options: 533 o The Hop-by-hop Options header. 535 o The Destination Options header. 537 The Hop-by-hop option can be examined by each node along the path to 538 a packet's destination. Destination options are examined by the 539 destination node only. However, [RFC2473] provides a precedent for 540 intermediate nodes examining the Destination options on an exception 541 basis. (See the Tunnel Encapsulation Limit.) 543 The Truncation Eligible option and the Truncated Packet option are 544 examined by: 546 o Intermediate nodes, on an exception basis (i.e, when the packet 547 cannot be forwarded due to MTU issues). 549 o The Destination node. 551 Therefore, the above-mentioned options can be processed most 552 efficiently when they are contained by the Destination Option header. 553 When contained by the Destination Options header, the above-mentioned 554 options are examined by intermediate nodes on an exception basis, 555 only when they are relevant. If contained by the Hop-by-hop Options 556 header, they are always examined by intermediate nodes, even when 557 they are irrelevant. 559 14. Security Considerations 561 PMTUD is vulnerable to ICMP PTB forgery attacks. The procedures 562 described herein do nothing to mitigate that vulnerability. 564 The procedures described herein are susceptible to a new variation on 565 that attack, in which an attacker forges a truncated packet. In this 566 case, the attackers cause the Destination Node to produce an ICMP PTB 567 message on their behalf. To some degree, this vulnerability is 568 mitigated, because the Destination Node will not emit an ICMP PTB 569 message in response to a truncated packet whose length is less than 570 the IPv6 minimum link MTU. 572 15. IANA Considerations 574 IANA is requested to allocate the following codepoints from the 575 Destination Options and Hop-by-hop Options registry 576 (https://www.iana.org/assignments/ipv6-parameters/ 577 ipv6-parameters.xhtml#ipv6-parameters-2). 579 o Truncation Eligible ("act-bits" are "00. "chg-bit" can be either 0 580 or 1.) 582 o Truncated Packet ("act-bits" are "10". "chg-but can be either 0 or 583 1.) 585 16. Acknowledgements 587 Special thanks to Mike Heard, Geoff Huston, Joel Jaeggli, Tom Jones, 588 Andy Smith, and Jinmei Tatuya who reviewed and commented on this 589 document. 591 17. References 593 17.1. Normative References 595 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 596 Requirement Levels", BCP 14, RFC 2119, 597 DOI 10.17487/RFC2119, March 1997, 598 . 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 17.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-01 (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 655 Ron Bonica 656 Juniper Networks 657 2251 Corporate Park Drive 658 Herndon, Virginia 20171 659 USA 661 Email: rbonica@juniper.net