Internet DRAFT - draft-leddy-6man-truncate
draft-leddy-6man-truncate
6man J. Leddy
Internet-Draft Unaffiliated
Intended status: Standards Track R. Bonica
Expires: April 15, 2019 Juniper Networks
I. Lubashev
Akamai Technologies
October 12, 2018
IPv6 Packet Truncation
draft-leddy-6man-truncate-05
Abstract
This document defines IPv6 packet truncation procedures. These
procedures make Path MTU Discovery (PMTUD) more reliable. Upper-
layer protocols can leverage these procedures in order to take
advantage of large MTUs.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 15, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Leddy, et al. Expires April 15, 2019 [Page 1]
Internet-Draft IPv6 Packet Truncation October 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Operational Considerations . . . . . . . . . . . . . . . . . 5
4. IPv6 Destination Options . . . . . . . . . . . . . . . . . . 6
4.1. The Truncation Eligible Option . . . . . . . . . . . . . 6
4.2. The Truncated Packet Option . . . . . . . . . . . . . . . 7
5. Reference Topology . . . . . . . . . . . . . . . . . . . . . 8
6. Truncation Procedures . . . . . . . . . . . . . . . . . . . . 8
7. Additional Truncation Considerations . . . . . . . . . . . . 10
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 10
9. Checksum Considerations . . . . . . . . . . . . . . . . . . . 11
10. Invalid Packet Types . . . . . . . . . . . . . . . . . . . . 11
11. Network Considerations . . . . . . . . . . . . . . . . . . . 12
12. Encapsulating Security Payload Considerations . . . . . . . . 12
13. Extension Header Considerations . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 13
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
17.1. Normative References . . . . . . . . . . . . . . . . . . 14
17.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
An Internet path connects a source node to a destination node. A
path can contain links and routers.
Each link is constrained by the number of bytes that it can convey in
a single IP packet. This constraint is called the link Maximum
Transmission Unit (MTU). IPv6 [RFC8200] requires every link to have
an MTU of 1280 bytes or greater. This value is called IPv6 minimum
link MTU.
Likewise, each Internet path is constrained by the number of bytes
that it can convey in a single IP packet. This constraint is called
the Path MTU (PMTU). For any given path, the PMTU is equal to the
smallest of its link MTUs.
IPv6 allows fragmentation at the source node only. If an IPv6 source
node sends a packet whose length exceeds the PMTU, an intermediate
node will discard the packet. In order to prevent this, IPv6 nodes
can either:
Leddy, et al. Expires April 15, 2019 [Page 2]
Internet-Draft IPv6 Packet Truncation October 2018
o Refrain from sending packets whose length exceeds the IPv6 minimum
link MTU.
o Maintain a running estimate of the PMTU and refrain from sending
packets whose length exceeds that estimate.
In order to maintain a running estimate of the PMTU, IPv6 nodes can
execute Path MTU Discovery (PMTUD) [RFC8201] procedures. In these
procedures, the source node produces an initial PMTU estimate. This
initial estimate equals the MTU of the first link along the path to
the destination. It can be greater than the actual PMTU.
Having produced an initial PMTU estimate, the source node sends
packets to the destination node. If one of these packets is larger
than the actual PMTU, an intermediate node will not be able to
forward the packet through the next link along the path. Therefore,
the intermediate node discards the packet and sends an Internet
Control Message Protocol (ICMP) [RFC4443] Packet Too Big (PTB)
message to the source node. The ICMP PTB message indicates the MTU
of the link through which the packet could not be forwarded. The
source node uses this information to refine its PMTU estimate.
PMTUD relies on the network to deliver ICMP PTB messages from the
intermediate node to the source node. If the network cannot deliver
these messages, a persistent black hole can develop. In this
scenario, the source node sends a packet whose length exceeds the
PMTU. An intermediate node discards the packet and sends an ICMP PTB
message to the source. However, the network cannot deliver the ICMP
PTB message to the source. Therefore, the source node does not
update its PMTU estimate and it continues to send packets whose
length exceeds the PMTU. The intermediate node discards these
packets and sends more ICMP PTB messages to the source. These ICMP
PTB messages are lost, exactly as previous ICMP PTB messages were
lost.
In some operational scenarios (Section 3), networks cannot deliver
ICMP PTB messages from an intermediate node to the source node.
Therefore, enhanced procedures are required.
This document defines IPv6 packet truncation procedures. When an
IPv6 source node originates a packet, it executes the following
procedure:
o Mark the packet as being eligible for truncation.
o Forward the packet towards its destination.
Leddy, et al. Expires April 15, 2019 [Page 3]
Internet-Draft IPv6 Packet Truncation October 2018
If an intermediate node cannot forward the packet because of an MTU
issue, it executes the following procedure:
o Detect that the packet is eligible for truncation.
o Send an ICMP PTB message to the source node, with the MTU field
indicating the MTU of the link through which the packet could not
be forwarded.
o Truncate the packet.
o Mark the packet as being truncated.
o Update the packet's upper-layer checksum (if possible).
o Forward the packet towards its destination.
When the destination node receives the packet, it executes the
following procedure:
o Detect that the packet has been truncated.
o Send an ICMP PTB message to the source node, with the MTU field
indicating the length of the truncated packet.
o Discard the packet.
Both ICMP PTB messages, mentioned above, contain MTU information that
the source node can use to refine its PMTU estimate.
The procedures described herein prevent incomplete (i.e., truncated)
data from being delivered to upper-layer protocols. While IPv6
packet truncation may facilitate new upper-layer procedures, upper-
layer procedures are beyond the scope of this document.
The procedures described herein make PMTUD more reliable by
increasing the probability that the source node will receive ICMP PTB
feedback from a downstream device. Even when the network cannot
deliver ICMP PTB messages from an intermediate router to a source
node, it may be able to deliver an ICMP PTB messages from the
destination node to the source node.
However, the procedures described herein do not make PMTUD one
hundred per cent reliable. In some operational scenarios, the
network cannot deliver any ICMP messages to the source node,
regardless of their origin.
Leddy, et al. Expires April 15, 2019 [Page 4]
Internet-Draft IPv6 Packet Truncation October 2018
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Operational Considerations
The packet truncation procedures described herein make PMTUD more
resilient when:
o The network can deliver ICMP messages from the destination node to
the source node.
o The network cannot deliver ICMP messages from an intermediate node
to the source node.
The following are common operational scenarios in which packet
truncation procedures can make PMTUD more resilient:
o The destination node has a viable route to the source node, but
the intermediate node does not.
o The source node is protected by a firewall that administratively
blocks all packets except for those from specified subnetworks.
The destination node resides in one of the specified subnetworks,
but the intermediate node does not.
o The source address of the original packet (i.e., the packet that
elicited the ICMP message) was an anycast address. Therefore, the
destination address of the ICMP message is the same anycast
address. In this case, an ICMP message from the destination node
is likely to be delivered to the correct anycast instance. By
contrast, an ICMP message from an intermediate node is less likely
to be delivered to the correct anycast instance.
Packet truncation procedures do not make PMTUD more resilient when
the network cannot reliably deliver any ICMP messages to the source
node. The following are operational scenarios where the network
cannot reliably deliver any ICMP PTB messages to the source node:
o The source node is protected by a firewall that administratively
blocks all ICMP messages.
Leddy, et al. Expires April 15, 2019 [Page 5]
Internet-Draft IPv6 Packet Truncation October 2018
o The source node is an anycast instance served by a load-balancer
as defined in [RFC7690]. The load-balancer does not implement the
mitigations defined in [RFC7690].
4. IPv6 Destination Options
This document defines the following IPv6 Destination options:
4.1. The Truncation Eligible Option
The Truncation Eligible option indicates that the packet is eligible
for truncation. It also indicates that the packet has not been
truncated.
The Truncation Eligible option contains the following fields:
o Option Type - Truncation Eligible option. Value TBD by IANA. See
Notes below.
o Opt Data Len - Length of Option Data, measured in bytes. MUST be
equal to 0.
IPv6 packets that include the Fragment header MUST NOT include the
Truncation Eligible option.
IPv6 packets whose length is less than the IPv6 minimum link MTU
SHOULD NOT include the Truncation Eligible option.
The IPv6 Hop-by-hop Options header SHOULD NOT include the Truncation
Eligible option.
The IPv6 Destination Options header:
o MAY include a single instance of the Truncation Eligible option.
o SHOULD NOT include multiple instances of the Truncation Eligible
option.
o MUST NOT include both the Truncation Eligible option and the
Truncated Packet option (Section 4.2).
NOTE 1: According to [RFC8200], the highest-order two bits of the
Option Type (i.e., the "act" bits) specify the action taken by a
processing node that does not recognize Option Type. The required
action is skip over this option and continue processing the header.
Therefore, IANA is requested to assign this Option Type with "act"
bits "00".
Leddy, et al. Expires April 15, 2019 [Page 6]
Internet-Draft IPv6 Packet Truncation October 2018
NOTE 2: According to [RFC8200], the third-highest-order bit (i.e.,
the "chg" bit) of the Option Type specifies whether Option Data can
change on route to the packet's destination. Because this option
contains no Option Data, IANA can assign this Option Type without
regard to the "chg" bit.
4.2. The Truncated Packet Option
The Truncated Packet option indicates that the packet has been
truncated and is eligible for further truncation.
The Truncated Packet option contains the following fields:
o Option Type - Truncated Packet option. Value TBD by IANA. See
Notes below.
o Opt Data Len - Length of Option Data, measured in bytes. MUST be
equal to 0.
IPv6 packets that include the Fragment header MUST NOT include the
Truncated Packet option.
IPv6 packets whose length is less than the IPv6 minimum link MTU MUST
NOT include the Truncated Packet option.
The IPv6 Hop-by-hop Options header SHOULD NOT include the Truncated
Packet option.
The IPv6 Destination Options:
o MAY include a single instance of the Truncated Packet option.
o SHOULD NOT include multiple instances of the Truncated Packet
option.
o MUST NOT include both the Truncated Packet option and the
Truncation Eligible option.
NOTE 1: According to [RFC8200], the highest-order two bits of the
Option Type (i.e., the "act" bits) specify the action taken by a
processing node that does not recognize Option Type. The required
action is to discard the packet and send an ICMP Parameter Problem,
Code 2, message to the packet's Source Address, pointing to the
unrecognized Option Type. Therefore, IANA is requested to assign
this Option Type with "act" bits "10".
NOTE 2: According to [RFC8200], the third-highest-order bit (i.e.,
the "chg" bit) of the Option Type specifies whether Option Data of
Leddy, et al. Expires April 15, 2019 [Page 7]
Internet-Draft IPv6 Packet Truncation October 2018
that option can change on route to the packet's destination. Because
this option contains no Option Data, IANA can assign this Option Type
without regard to the "chg" bit.
5. Reference Topology
----------- ----------- ----------- -----------
| Upper | | | | | | Upper |
| Layer | | | | | | Layer |
| | | | | | | |
| IP |<-------->| IP |<-------->| IP |<-------->| IP |
| Layer | MTU | Layer | MTU | Layer | MTU | Layer |
----------- 9000 ----------- 4000 ----------- 1500 -----------
Source Router 1 Router 2 Destination
Node Node
Figure 1: Reference Topology
Figure 1 depicts a network that contains a Source Node, intermediate
nodes (i.e., Router 1, Router 2), and a Destination Node. The link
that connects the Source Node to Router 1 has an MTU of 9000 bytes.
The link that connects Router 1 to Router 2 has an MTU of 4000 bytes,
and the link that connects Router 2 to the Destination Node has an
MTU of 1500 bytes. The PMTU between the Source Node and the
Destination Node is 1500 bytes.
This topology is used in examples throughout the document.
6. Truncation Procedures
In the Reference Topology (Figure 1), the Source Node produces an
initial estimate of the PMTU between itself and the Destination Node.
This initial estimate equals the MTU of the first link on the path to
the Destination Node (e.g., 9000 bytes).
The Source Node refrains from sending packets whose length exceeds
the above-mentioned estimate. However, the above-mentioned estimate
is significantly larger than the actual PMTU (1500 bytes).
Therefore, the Source Node may send packets whose length exceeds the
actual PMTU.
At some time in the future, an upper-layer protocol on the Source
Node causes the IP layer to emit a packet. The packet contains a
Destination Options header and the Destination Options header
contains a Truncation Eligible option. The total packet length,
including all headers and the payload, is 1350 bytes. Because the
total packet length is less than the actual PMTU, this packet can be
Leddy, et al. Expires April 15, 2019 [Page 8]
Internet-Draft IPv6 Packet Truncation October 2018
delivered to the Destination Node without encountering any MTU
issues.
The IP layer on the Source Node forwards the packet to the Router 1,
Router 1 forwards the packet to Router 2, and the Router 2 forwards
the packet to the Destination Node. The IP layer on the Destination
Node examines the Destination Options header and finds the Truncation
Eligible option. The Truncation Eligible option requires no action
by the Destination Node. Therefore, the Destination Node processes
the next header and delivers the packet to an upper-layer protocol.
Subsequently, the same upper-layer protocol on the Source Node causes
the IP layer to emit another packet. This packet is identical to the
first, except that the total packet length is 2000 bytes. Because
the packet length is greater than the actual PMTU, this packet cannot
be delivered without encountering an MTU issue.
The IP layer on the source node forwards the packet to Router 1.
Router 1 forwards the packet to Router 2, but the Router 2 cannot
forward the packet because its length exceeds the MTU of the next
link in the path (i.e., 1500 bytes). Because an MTU issue has been
encountered, Router 2 examines the Destination Options header,
searching for either a Truncation Eligible option or a Truncated
Packet option. (Normally, the Router 2 would ignore the Destination
Options header).
Because Router 2 finds one of the above-mentioned options, it:
o Sends an ICMP PTB message to the Source Node. The ICMP PTB
message contains an MTU field indicating the MTU of the next link
in the path (i.e. 1500 bytes).
o Truncates the packet, so that its total length equals the MTU of
the next link in the path.
o Updates the IPv6 Payload Length.
o Overwrites all instances of the Truncation Eligible option with a
Truncated Packet option.
o Updates the upper-layer checksum (if possible)
o Forwards the packet to the Destination Node.
The IP layer on the Destination Node receives the packet and examines
the Destination Options header. Because it finds the Truncated
Packet option, it discards the packet and sends an ICMP PTB message
Leddy, et al. Expires April 15, 2019 [Page 9]
Internet-Draft IPv6 Packet Truncation October 2018
to the Source Node. The MTU field in the ICMP PTB message represents
the length of the received packet.
When the Source Node receives the ICMP PTB message, it updates its
PMTU estimate, as per [RFC8201].
7. Additional Truncation Considerations
A packet can be truncated multiple times. In the Reference Topology
(Figure 1), assume that the Source Node sends a 5000 byte packet to
the Destination Node. Using the procedures described in Section 6,
Router 1 truncates this packet to 4000 bytes and Router 2 truncates
it again, to 1500 bytes.
A truncated packet MUST contain the basic IPv6 header, all extension
headers and the first upper-layer header. When an intermediate node
cannot forward a packet due to MTU issues, and the total length of
the basic IPv6 header, all extension headers, and first upper-layer
header exceeds the MTU of the next link in the path, the intermediate
node MUST discard the packet and send and ICMP PTB message to the
source node. It MUST NOT truncate the packet.
A truncated packet MUST NOT include the Fragment header. When an
intermediate node cannot forward a packet due to MTU issues, and the
packet contains a Fragment header, the intermediate node MUST discard
the packet and send and ICMP PTB message to the source node. It MUST
NOT truncate the packet.
A truncated packet must have a total length that is greater than or
equal to the IPv6 minimum link MTU.
8. Backwards Compatibility
Section 6 of this document assumes that all nodes recognize the
Truncation Eligible and Truncated Packet options. This section
explores backwards compatibility issues, where one or more nodes do
not recognize the above-mentioned options.
An intermediate node that does not recognize the above-mentioned
options behaves exactly as described in [RFC8200]. When it receives
a packet that does not cause an MTU issue, it processes the packet.
When it receives a packet that causes an MTU issue, it discards the
packet and sends an ICMP PTB message to the source node. In neither
case does the intermediate node examine the Destination Options
header or truncate the packet.
A destination node that does not recognize the Truncation Eligible
option also behaves exactly as described in [RFC8200]. When it
Leddy, et al. Expires April 15, 2019 [Page 10]
Internet-Draft IPv6 Packet Truncation October 2018
receives a packet that contains the Truncation Eligible option, its
behavior is determined by the highest-order two bits of the Option
Type (i.e., the "act" bits). Because the "act" bits are equal to
"00", the destination node skips over the option and continues to
process the packet. This is exactly what the destination node would
have done if it had recognized the Truncation Eligible option.
A destination node that does not recognize the Truncated Packet
option also behaves exactly as described in [RFC8200]. When it
receives a packet that contains the Truncated Packet option, its
behavior is determined by the highest-order two bits of the Option
Type (i.e., the "act" bits). Because the "act" bits are equal to
"10", the destination node discards the packet and sends an ICMP
Parameter Problem, Code 2, message to the packet's Source Address,
pointing to the Truncated Packet option. The destination node does
not emit an ICMP PTB message.
The source node takes appropriate action when it receives the ICMP
Parameter Problem message.
9. Checksum Considerations
When an intermediate node truncates a packet, it SHOULD update the
upper-layer checksum, if possible. This is desirable because it
increases the probability that the truncated packet will be delivered
to the destination node.
Middleboxes residing downstream of the intermediate node may attempt
to validate the upper-layer checksum. If validation fails, they may
discard the packet without sending an ICMP message.
10. Invalid Packet Types
The following packet types are invalid:
o Packets that contain the Fragment header and the Truncation
Eligible option.
o Packets that contain the Fragment header and the Packet Truncated
option.
o Packets that contain the Truncation Eligible option and the Packet
Truncated option.
o Packets that specify an Option Data Length greater than 0 in the
Truncation Eligible option.
Leddy, et al. Expires April 15, 2019 [Page 11]
Internet-Draft IPv6 Packet Truncation October 2018
o Packets that specify an Option Data Length greater than 0 in the
Truncated Packet option.
o Packets that have a total length less than the IPv6 minimum link
MTU and contain the Packet Truncated option.
If an intermediate node cannot forward one of the above-mentioned
packets because of an MTU issue, its behavior is as described in
[RFC8200]. The intermediate node discards the packet and sends an
ICMP PTB message to the source node. It does not truncate or forward
the packet.
When the destination node receives one of the above-mentioned
packets, it MUST:
o Discard the packet
o Send an ICMP Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the first invalid option.
The destination node MUST NOT send an ICMP PTB message.
11. Network Considerations
The procedures described herein rely upon the networks ability:
o To convey packets that contain destination options from the source
node to the destination node.
o To convey ICMP Parameter Problem messages in the reverse
direction.
Operational experience [RFC7872] reveals that a significant number of
networks drop packets that contain IPv6 destination options.
Likewise, many networks drop ICMP Parameter Problem messages.
[I-D.bonica-6man-unrecognized-opt] describes procedures that upper-
layer protocols can execute to verify that the above-mentioned
requirements are satisfied. Upper-layer protocols can execute these
procedures before emitting packets that contain the Truncation
Eligible option.
12. Encapsulating Security Payload Considerations
An IPv6 packet can contain both:
o An Encapsulating Security Payload (ESP) [RFC4303] header.
Leddy, et al. Expires April 15, 2019 [Page 12]
Internet-Draft IPv6 Packet Truncation October 2018
o Truncation options (i.e., the Truncation Eligible or Truncated
Packet options).
In this case, the packet MUST contain a Destination Options header
that precedes the ESP. That Destination Options header contains the
truncation options and is not protected by the ESP. The packet MAY
also contain another Destination Options header the follows the ESP.
That Destination Options header is protected by the ESP and MUST NOT
contain the truncation options.
As per RFC 4303, a packet can contain two Destination Options headers
one preceding the ESP and one following the ESP.
13. Extension Header Considerations
According to [RFC8200], the following IPv6 extension headers can
contain options:
o The Hop-by-hop Options header.
o The Destination Options header.
The Hop-by-hop option can be examined by each node along the path to
a packet's destination. Destination options are examined by the
destination node only. However, [RFC2473] provides a precedent for
intermediate nodes examining the Destination options on an exception
basis. (See the Tunnel Encapsulation Limit.)
The truncation options described herein are examined by:
o Intermediate nodes, on an exception basis (i.e, when the packet
cannot be forwarded due to MTU issues).
o The Destination node.
Therefore, the above-mentioned options can be processed most
efficiently when they are contained by the Destination Option header.
When contained by the Destination Options header, the above-mentioned
options are examined by intermediate nodes on an exception basis,
only when they are relevant. If contained by the Hop-by-hop Options
header, they are always examined by intermediate nodes, even when
they are irrelevant.
14. Security Considerations
PMTUD is vulnerable to ICMP PTB forgery attacks. The procedures
described herein do nothing to mitigate that vulnerability.
Leddy, et al. Expires April 15, 2019 [Page 13]
Internet-Draft IPv6 Packet Truncation October 2018
The procedures described herein are susceptible to a new variation on
that attack, in which an attacker forges a truncated packet. In this
case, the attackers cause the Destination Node to produce an ICMP PTB
message on their behalf. To some degree, this vulnerability is
mitigated, because the Destination Node will not emit an ICMP PTB
message in response to a truncated packet whose length is less than
the IPv6 minimum link MTU.
In order to mitigate denial of service attacks, intermediate nodes
MUST rate limit the number of packets that they truncate per second.
15. IANA Considerations
IANA is requested to allocate the following codepoints from the
Destination Options and Hop-by-hop Options registry
(https://www.iana.org/assignments/ipv6-parameters/
ipv6-parameters.xhtml#ipv6-parameters-2).
o Truncation Eligible ("act-bits" are "00. "chg-bit" can be either 0
or 1.)
o Truncated Packet ("act-bits" are "10". "chg-but can be either 0 or
1.)
16. Acknowledgements
Special thanks to Mike Heard, Geoff Huston, Joel Jaeggli, Tom Jones,
Andy Smith, Jinmei Tatuya, and Reji Thomas who reviewed and commented
on this document.
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
Leddy, et al. Expires April 15, 2019 [Page 14]
Internet-Draft IPv6 Packet Truncation October 2018
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
17.2. Informative References
[I-D.bonica-6man-unrecognized-opt]
Bonica, R. and J. Leddy, "The IPv6 Probe Option", draft-
bonica-6man-unrecognized-opt-03 (work in progress), August
2018.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of
the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too
Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016,
<https://www.rfc-editor.org/info/rfc7690>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>.
Authors' Addresses
John Leddy
Unaffiliated
Email: john@leddy.net
Leddy, et al. Expires April 15, 2019 [Page 15]
Internet-Draft IPv6 Packet Truncation October 2018
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
USA
Email: rbonica@juniper.net
Igor Lubashev
Akamai Technologies
Cambridge, MA
USA
Email: ilubashe@akamai.com
Leddy, et al. Expires April 15, 2019 [Page 16]
