draft-ietf-6man-icmp-limits-08.txt   rfc8883.txt 
Network Working Group T. Herbert Internet Engineering Task Force (IETF) T. Herbert
Internet-Draft Intel Request for Comments: 8883 Intel
Intended status: Standards Track March 18, 2020 Category: Standards Track September 2020
Expires: September 19, 2020 ISSN: 2070-1721
ICMPv6 errors for discarding packets due to processing limits ICMPv6 Errors for Discarding Packets Due to Processing Limits
draft-ietf-6man-icmp-limits-08
Abstract Abstract
Network nodes may discard packets if they are unable to process Network nodes may discard packets if they are unable to process
protocol headers of packets due to processing constraints or limits. protocol headers of packets due to processing constraints or limits.
When such packets are dropped, the sender receives no indication so When such packets are dropped, the sender receives no indication, so
it cannot take action to address the cause of discarded packets. it cannot take action to address the cause of discarded packets.
This specification defines several new ICMPv6 errors that can be sent This specification defines several new ICMPv6 errors that can be sent
by a node that discards packets because it is unable to process the by a node that discards packets because it is unable to process the
protocol headers. A node that receives such an ICMPv6 error may use protocol headers. A node that receives such an ICMPv6 error may use
the information to diagnose packet loss and may modify what it sends the information to diagnose packet loss and may modify what it sends
in future packets to avoid subsequent packet discards. in future packets to avoid subsequent packet discards.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 19, 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8883.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Extension header limits . . . . . . . . . . . . . . . . . 3 1.1. Extension Header Limits
1.2. Aggregate header limits . . . . . . . . . . . . . . . . . 4 1.2. Aggregate Header Limits
1.3. Nonconformant packet discard . . . . . . . . . . . . . . 4 1.3. Nonconformant Packet Discard
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Terminology
2. ICMPv6 errors for extension header limits . . . . . . . . . . 5 2. ICMPv6 Errors for Extension Header Limits
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Format
2.2. Unrecognized Next Header type encountered by intermediate 2.2. Unrecognized Next Header Type Encountered by Intermediate
node (code TBA1) . . . . . . . . . . . . . . . . . . . . 6 Node (Code 5)
2.3. Extension header too big (code TBA2) . . . . . . . . . . 6 2.3. Extension Header Too Big (Code 6)
2.4. Extension header chain too long (code TBA3) . . . . . . . 6 2.4. Extension Header Chain Too Long (Code 7)
2.5. Too many extension headers (code TBA4) . . . . . . . . . 6 2.5. Too Many Extension Headers (Code 8)
2.6. Too many options in extension header (code TBA5) . . . . 7 2.6. Too Many Options in Extension Header (Code 9)
2.7. Option too big (code TBA6) . . . . . . . . . . . . . . . 7 2.7. Option Too Big (Code 10)
3. ICMPv6 error for aggregate header limits . . . . . . . . . . 7 3. ICMPv6 Error for Aggregate Header Limits
3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Format
3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Usage
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Operation
4.1. Priority of reporting . . . . . . . . . . . . . . . . . . 10 4.1. Priority of Reporting
4.2. Host response . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Host Response
5. Applicability and use cases . . . . . . . . . . . . . . . . . 11 5. Applicability and Use Cases
5.1. Reliability of ICMP . . . . . . . . . . . . . . . . . . . 12 5.1. Reliability of ICMP
5.2. Processing limits . . . . . . . . . . . . . . . . . . . . 12 5.2. Processing Limits
5.2.1. Long headers and header chains . . . . . . . . . . . 12 5.2.1. Long Headers and Header Chains
5.2.2. At end hosts . . . . . . . . . . . . . . . . . . . . 12 5.2.2. At End Hosts
5.2.3. At intermediate nodes . . . . . . . . . . . . . . . . 13 5.2.3. At Intermediate Nodes
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations
7.1. Parameter Problem codes . . . . . . . . . . . . . . . . . 13 7.1. Parameter Problem Codes
7.2. Destination Unreachable codes . . . . . . . . . . . . . . 14 7.2. Destination Unreachable Codes
7.3. ICMP Extension Object Classes and Class Sub-types . . . . 14 7.3. ICMP Extension Object Classes and Class Sub-types
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address
1. Introduction 1. Introduction
This document specifies several new ICMPv6 errors that can be sent This document specifies several new ICMPv6 errors that can be sent
when a node discards a packet due to it being unable to process the when a node discards a packet due to it being unable to process the
necessary protocol headers because of processing constraints or necessary protocol headers because of processing constraints or
limits. New ICMPv6 code points are defined to supplement those limits. New ICMPv6 code points are defined to supplement those
defined in [RFC4443]. Six of the errors are specific to processing defined in [RFC4443]. Six of the errors are specific to the
of extension headers; another error is used when the aggregate processing of extension headers; another error is used when the
protocol headers in a packet exceed the processing limits of a node. aggregate protocol headers in a packet exceed the processing limits
of a node.
1.1. Extension header limits 1.1. Extension Header Limits
In IPv6, optional internet-layer information is carried in one or In IPv6, optional internet-layer information is carried in one or
more IPv6 Extension Headers [RFC8200]. Extension Headers are placed more IPv6 extension headers [RFC8200]. Extension headers are placed
between the IPv6 header and the Upper-Layer Header in a packet. The between the IPv6 header and the upper-layer header in a packet. The
term "Header Chain" refers collectively to the IPv6 header, Extension term "header chain" refers collectively to the IPv6 header, extension
Headers, and Upper-Layer Headers occurring in a packet. Individual headers, and upper-layer headers occurring in a packet. Individual
extension headers may have a maximum length of 2048 octets and must extension headers may have a maximum length of 2048 octets and must
fit into a single packet. Destination Options and Hop-by-Hop Options fit into a single packet. Destination Options and Hop-by-Hop Options
contain a list of options in Type-length-value (TLV) format. Each contain a list of options in type-length-value (TLV) format. Each
option includes a length of the data field in octets: the minimum option includes a length of the data field in octets: the minimum
size of an option (non-pad type) is two octets and the maximum size size of an option (non-pad type) is two octets, and the maximum size
is 257 octets. The number of options in an extension header is only is 257 octets. The number of options in an extension header is only
limited by the length of the extension header and the Path MTU from limited by the length of the extension header and the Path MTU from
the source to the destination. Options may be skipped over by a the source to the destination. Options may be skipped over by a
receiver if they are unknown and the Option Type indicates to skip receiver if they are unknown and the Option Type indicates to skip
(first two high order bits are 00). (first two high order bits are 00).
Per [RFC8200], except for Hop by Hop options, extension headers are Per [RFC8200], except for Hop-by-Hop Options, extension headers are
not examined or processed by intermediate nodes. Many intermediate not examined or processed by intermediate nodes. However, in
nodes, however, do examine extension headers for various purposes. deployed networks, many intermediate nodes do examine extension
For instance, a node may examine all extension headers to locate the headers for various purposes. For instance, a node may examine all
transport header of a packet in order to implement transport layer extension headers to locate the transport header of a packet in order
filtering or to track connections to implement a stateful firewall. to implement transport-layer filtering or to track connections to
implement a stateful firewall.
Destination hosts are expected to process all extension headers and Destination hosts are expected to process all extension headers and
options in Hop-by-Hop and Destination Options. options in Hop-by-Hop and Destination Options.
Due to the variable lengths, high maximum lengths, or potential for Due to the variable lengths, high maximum lengths, or potential for a
Denial of Service attack of extension headers, many devices impose denial-of-service attack of extension headers, many devices impose
operational limits on extension headers in packets they process. operational limits on extension headers in packets they process.
[RFC7045] discusses the requirements of intermediate nodes that [RFC7045] discusses the requirements of intermediate nodes that
discard packets because of unrecognized extension headers. [RFC8504] discard packets because of unrecognized extension headers. [RFC8504]
discusses limits that may be applied to the number of options in Hop- discusses limits that may be applied to the number of options in Hop-
by-Hop Options or Destination Options extension headers. Both by-Hop Options or Destination Options extension headers. Both
intermediate nodes and end hosts may apply limits to extension header intermediate nodes and end hosts may apply limits to extension header
processing. When a limit is exceeded, the typical behavior is to processing. When a limit is exceeded, the typical behavior is to
silently discard the packet. silently discard the packet.
This specification defines six Parameter Problem codes that may be This specification defines six Parameter Problem codes that may be
sent by a node that discards a packet due to processing limits of sent by a node that discards a packet due to the processing limits of
extension headers being exceeded. The information in these ICMPv6 extension headers being exceeded. The information in these ICMPv6
errors may be used for diagnostics to determine why packets are being errors may be used for diagnostics to determine why packets are being
dropped. Additionally, a source node that receives these ICMPv6 dropped. Additionally, a source node that receives these ICMPv6
errors may be able to modify its use of extension headers in errors may be able to modify its use of extension headers in
subsequent packets sent to the destination in order to avoid further subsequent packets sent to the destination in order to avoid further
occurrences of packets being discarded. occurrences of packets being discarded.
1.2. Aggregate header limits 1.2. Aggregate Header Limits
Some hardware devices implement a parsing buffer of a fixed size to Some hardware devices implement a parsing buffer of a fixed size to
process packets. The parsing buffer is expected to contain all the process packets. The parsing buffer is expected to contain all the
headers (often up to a transport layer header for filtering) that a headers (often up to a transport-layer header for filtering) that a
device needs to examine. If the aggregate length of headers in a device needs to examine. If the aggregate length of headers in a
packet exceeds the size of the parsing buffer, a device will either packet exceeds the size of the parsing buffer, a device will either
discard the packet or will defer processing to a software slow path. discard the packet or defer processing to a software slow path. In
In any case, no indication of a problem is sent back to the sender. any case, no indication of a problem is sent back to the sender.
This document defines one code for ICMPv6 Destination Unreachable This document defines one code for ICMPv6 Destination Unreachable
that is sent by a node that is unable to process the headers of a that is sent by a node that is unable to process the headers of a
packet due to the aggregate size of the packet headers exceeding a packet due to the aggregate size of the packet headers exceeding a
processing limit. The information in this ICMPv6 error may be used processing limit. The information in this ICMPv6 error may be used
for diagnostics to determine why packets are being dropped. for diagnostics to determine why packets are being dropped.
Additionally, a source node that receives this ICMPv6 error may be Additionally, a source node that receives this ICMPv6 error may be
able to modify the headers used in subsequent packets to try to avoid able to modify the headers used in subsequent packets to try to avoid
further occurrences of packets being discarded. further occurrences of packets being discarded.
1.3. Nonconformant packet discard 1.3. Nonconformant Packet Discard
The ICMP errors defined in this specification may be applicable to The ICMP errors defined in this specification may be applicable to
scenarios for which a node is dropping packets outside the auspices scenarios in which a node is dropping packets outside the auspices of
of any standard specification. For instance, an intermediate node any standard specification. For instance, an intermediate node might
might send a "Headers too long" code in the case that it drops a send a "Headers too long" code in a case where it drops a packet
packet because it is unable to parse deep enough to extract transport because it is unable to parse deeply enough to extract the transport-
layer information needed for packet filtering. Such behavior might layer information needed for packet filtering. Such behavior might
be considered nonconformant (with respect to [RFC8200] for instance). be considered nonconformant (with respect to [RFC8200], for
instance).
This specification does not advocate behaviors that might be This specification does not advocate behaviors that might be
considered nonconformant. However, packet discard does occur in real considered nonconformant. However, packet discard does occur in real
deployments and the intent of this specification is provide deployments, and the intent of this specification is to provide
visibility as to why packets are being discarded. In the spirit that visibility as to why packets are being discarded. In the spirit that
providing some reason is better than silent drop, the sending of ICMP providing some reason is better than a silent drop, the sending of
errors is RECOMMENDED even in cases where a node might be discarding ICMP errors is RECOMMENDED even in cases where a node might be
packets per a nonconformant behavior. discarding packets per a nonconformant behavior.
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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.
2. ICMPv6 errors for extension header limits 2. ICMPv6 Errors for Extension Header Limits
Six new codes are defined for the Parameter Problem type. Six new codes are defined for the Parameter Problem type.
2.1. Format 2.1. Format
The format of the ICMPv6 Parameter Problem message [RFC4443] for an The format of the ICMPv6 Parameter Problem message [RFC4443] for an
extension header limit exceeded error is: extension header limit exceeded error is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer | | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet | | |
| As much of the invoking packet |
+ as possible without the ICMPv6 packet + + as possible without the ICMPv6 packet +
| exceeding the minimum IPv6 MTU [RFC8200] | | exceeding the minimum IPv6 MTU [RFC8200] |
IPv6 Header Fields: IPv6 Header Fields:
Destination Address:
Destination Address
Copied from the Source Address field of the invoking packet. Copied from the Source Address field of the invoking packet.
ICMPv6 Fields: ICMPv6 Fields:
Type:
4 (Parameter Problem type)
Type Code:
4 (Parameter Problem type) (pertinent to this specification)
Code (pertinent to this specification) +----+----------------------------------+
| 5 | Unrecognized Next Header type |
| | encountered by intermediate node |
+----+----------------------------------+
| 6 | Extension header too big |
+----+----------------------------------+
| 7 | Extension header chain too long |
+----+----------------------------------+
| 8 | Too many extension headers |
+----+----------------------------------+
| 9 | Too many options in extension |
| | header |
+----+----------------------------------+
| 10 | Option too big |
+----+----------------------------------+
TBA1 - Unrecognized Next Header type encountered by Table 1
intermediate node
TBA2 - Extension header too big
TBA3 - Extension header chain too long
TBA4 - Too many extension headers
TBA5 - Too many options in extension header
TBA6 - Option too big
Pointer Pointer:
Identifies the octet offset within the invoking packet where Identifies the octet offset within the invoking packet where
the problem occurred. the problem occurred.
The pointer will point beyond the end of the Invoking Packet if The pointer will point beyond the end of the IPv6 packet if the
the field exceeding the limit is beyond what can fit in the field exceeding the limit is beyond what can fit in the maximum
maximum size of an ICMPv6 error message extension. If the size of an ICMPv6 error message. If the pointer is used as an
pointer is used as an offset to read the data in the invoking offset to read the data in the invoking packet, then a node
packet then a node MUST first validate that the pointer value MUST first validate that the pointer value is less than the
is less than the length of the Invoking Packet data. length of the invoking packet data.
2.2. Unrecognized Next Header type encountered by intermediate node 2.2. Unrecognized Next Header Type Encountered by Intermediate Node
(code TBA1) (Code 5)
This code SHOULD be sent by an intermediate node that discards a This code SHOULD be sent by an intermediate node that discards a
packet because it encounters a Next Header type that is unknown in packet because it encounters a Next Header type that is unknown in
its examination. The ICMPv6 Pointer field is set to the offset of its examination. The ICMPv6 Pointer field is set to the offset of
the unrecognized next header value within the original packet. the unrecognized Next Header value within the original packet.
Note that this code is sent by intermediate nodes, and SHOULD NOT be Note that this code is sent by intermediate nodes and SHOULD NOT be
sent by a final destination. If a final destination node observes an sent by a final destination. If a final destination node observes an
unrecognized header then it SHOULD send an ICMP Parameter Problem unrecognized header, then it SHOULD send an ICMP Parameter Problem
message with an ICMP Code value of 1 ("unrecognized Next Header type message with an ICMP Code value of 1 ("unrecognized Next Header type
encountered") as specified in [RFC8200]. encountered") as specified in [RFC8200].
2.3. Extension header too big (code TBA2) 2.3. Extension Header Too Big (Code 6)
An ICMPv6 Parameter Problem with code for "extension header too big" An ICMPv6 Parameter Problem with code for "Extension header too big"
SHOULD be sent when a node discards a packet because the size of an SHOULD be sent when a node discards a packet because the size of an
extension header exceeds its processing limit. The ICMPv6 Pointer extension header exceeds its processing limit. The ICMPv6 Pointer
field is set to the offset of the first octet in the extension header field is set to the offset of the first octet in the extension header
that exceeds the limit. that exceeds the limit.
2.4. Extension header chain too long (code TBA3) 2.4. Extension Header Chain Too Long (Code 7)
An ICMPv6 Parameter Problem with code for "extension header chain too An ICMPv6 Parameter Problem with code for "Extension header chain too
long" SHOULD be sent when a node discards a packet with an extension long" SHOULD be sent when a node discards a packet with an extension
header chain that exceeds a limit on the total size in octets of the header chain that exceeds a limit on the total size in octets of the
header chain. The ICMPv6 Pointer is set to first octet beyond the header chain. The ICMPv6 Pointer is set to the first octet beyond
limit. the limit.
2.5. Too many extension headers (code TBA4) 2.5. Too Many Extension Headers (Code 8)
An ICMPv6 Parameter Problem with code for "too many extension An ICMPv6 Parameter Problem with code for "Too many extension
headers" SHOULD be sent when a node discards a packet with an headers" SHOULD be sent when a node discards a packet with an
extension header chain that exceeds a limit on the number of extension header chain that exceeds a limit on the number of
extension headers in the chain. The ICMPv6 Pointer is set to the extension headers in the chain. The ICMPv6 Pointer is set to the
offset of first octet of the first extension header that is beyond offset of the first octet of the first extension header that is
the limit. beyond the limit.
2.6. Too many options in extension header (code TBA5) 2.6. Too Many Options in Extension Header (Code 9)
An ICMPv6 Parameter Problem with code for "too many options in An ICMPv6 Parameter Problem with code for "Too many options in
extension header" SHOULD be sent when a node discards a packet with extension header" SHOULD be sent when a node discards a packet with
an extension header that has a number of options that exceed the an extension header that has a number of options that exceeds the
processing limits of the node. This code is applicable for processing limits of the node. This code is applicable for
Destination options and Hop-by-Hop options. The ICMPv6 Pointer field Destination Options and Hop-by-Hop Options. The ICMPv6 Pointer field
is set to the first octet of the first option that exceeds the limit. is set to the first octet of the first option that exceeds the limit.
2.7. Option too big (code TBA6) 2.7. Option Too Big (Code 10)
An ICMPv6 Parameter Problem with code for "option too big" is sent in An ICMPv6 Parameter Problem with code for "Option too big" is sent in
two different cases: when the length of an individual Hop-by-Hop or two different cases: when the length of an individual Hop-by-Hop or
Destination option exceeds a limit, or when the length or number of Destination Option exceeds a limit, or when the length or number of
consecutive Hop-by-Hop or Destination padding options exceeds a consecutive Hop-by-Hop or Destination padding options exceeds a
limit. In the case that the length of an option exceeds a processing limit. In a case where the length of an option exceeds a processing
limit, the ICMPv6 Pointer field is set to the offset of the first limit, the ICMPv6 Pointer field is set to the offset of the first
octet of the option that exceeds the limit. In the cases that the octet of the option that exceeds the limit. In cases where the
length or number of padding options exceeds a limit, the ICMPv6 length or number of padding options exceeds a limit, the ICMPv6
Pointer field is set to the offset of first octet of the padding Pointer field is set to the offset of the first octet of the padding
option that exceeds the limit. option that exceeds the limit.
Possible limits related to padding include: Possible limits related to padding include:
* The number of consecutive PAD1 options in destination options * The number of consecutive PAD1 options in Destination Options or
or hop-by-hop options is limited to seven octets [RFC8504]. Hop-by-Hop Options is limited to seven octets [RFC8504].
* The length of a PADN options in destination options or hop-by- * The length of PADN options in Destination Options or Hop-by-Hop
hop options is limited seven octets [RFC8504]. Options is limited seven octets [RFC8504].
* The aggregate length of a set of consecutive PAD1 or PADN * The aggregate length of a set of consecutive PAD1 or PADN options
options in destination options or hop-by-hop options is limited in Destination Options or Hop-by-Hop Options is limited to seven
to seven octets. octets.
3. ICMPv6 error for aggregate header limits 3. ICMPv6 Error for Aggregate Header Limits
One code is defined for Destination Unreachable type for aggregate One code is defined for the Destination Unreachable type for
header limits. aggregate header limits.
This ICMP error may be applied to other headers in a packet than just This ICMP error may be applied to other headers in a packet than just
the IPv6 header or IPv6 extension headers. Therefore, a Destination the IPv6 header or IPv6 extension headers. Therefore, a Destination
Unreachable type with a multi-part ICMPv6 message format is used in Unreachable type with a multi-part ICMPv6 message format is used in
lieu of the Parameter Problem type which only indicates errors lieu of the Parameter Problem type, which only indicates errors
concerning IPv6 headers. concerning IPv6 headers.
3.1. Format 3.1. Format
The error for aggregate header limits employs a multi-part ICMPv6 The error for aggregate header limits employs a multi-part ICMPv6
message format as defined in [RFC4884]. The extension object class message format as defined in [RFC4884]. The extension object class
"Extended Information" is defined to contain objects for ancillary "Extended Information" is defined to contain objects for ancillary
information pertaining to an ICMP Destination Unreachable error. information pertaining to an ICMP Destination Unreachable error.
Within this object class, the sub-type "Pointer" is defined which Within this object class, the sub-type "Pointer" is defined, which
contains the Pointer field with similar semantics to the Pointer contains a Pointer field with similar semantics to the Pointer field
field in ICMP Parameter Problem errors. in ICMP Parameter Problem errors.
The format of the ICMPv6 message for an aggregate header limit The format of the ICMPv6 message for an aggregate header limit
exceeded is: exceeded is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Type | Code | Checksum | | | Type | Code | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Length | Unused | C | Length | Unused | C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
| Invoking Packet | P | | P
~ As much of invoking packet as possible without the ~ | ~ As much of the invoking packet ~
| ICMPv6 packet exceeding the minimum IPv6 MTU [RFC8200] |/ | as possible without the ICMPv6 packet |
| exceeding the minimum IPv6 MTU [RFC8200] |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
|Version| Reserved | Checksum |\ |Version| Reserved | Checksum |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E
| Length | Class-Num | C-Type | X | Length | Class-Num | C-Type | X
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
| Pointer | | | Pointer | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
IPv6 Header Fields: IPv6 Header Fields:
Destination Address:
Destination Address
Copied from the Source Address field of the invoking packet. Copied from the Source Address field of the invoking packet.
ICMPv6 Fields: ICMPv6 Fields:
Type:
1 - Destination Unreachable
Type Code: (pertinent to this specification)
1 - Destination Unreachable type 8 - Headers too long
Code (pertinent to this specification)
TBA7 - Headers too long
Length Length:
Length of the padded Invoking Packet measured in 64-bit words. Length of the padded invoking packet data measured in 64-bit
The ICMP extension structure immediately follows the padded words. The ICMP extension structure immediately follows the
Invoking Packet padded invoking packet data.
Invoking Packet Invoking Packet:
Contains as much of invoking packet as possible without the Contains as much of the invoking packet as possible without the
ICMPv6 packet exceeding the minimum IPv6 MTU. The Invoking ICMPv6 packet exceeding the minimum IPv6 MTU. The invoking
Packet MUST be zero padded to the nearest 64-bit boundary packet data MUST be zero padded to the nearest 64-bit boundary
[RFC4884]. If the original invoking packet did not contain 128 [RFC4884]. If the original invoking packet did not contain 128
octets, the Invoking Packet MUST be zero padded to 128 octets. octets, the invoking packet data MUST be zero padded to 128
octets.
ICMP Extension Fields: ICMP Extension Fields:
Version:
2 - per [RFC4884]
Version Reserved:
2 - per [RFC4884]
Reserved
0 0
Checksum Checksum:
The one's complement checksum of the ICMP extension [RFC4884] The one's complement checksum of the ICMP extension [RFC4884]
Length Length:
8 - length of the object header and Pointer field 8 - length of the object header and Pointer field
Class-Num Class-Num:
TBA8 - Extended Information class 4 - Extended Information
C-Type C-Type:
TBA9 - Pointer sub-type 1 - Pointer
Pointer Pointer:
Identifies the octet offset within the invoking packet where a Identifies the octet offset within the invoking packet where a
limit was exceeded. limit was exceeded.
The pointer will point beyond the end of the Invoking Packet if The pointer will point beyond the end of the invoking packet
the field exceeding the limit is beyond what can fit in the data if the field exceeding the limit is beyond what can fit in
maximum size of an ICMPv6 error message with the ICMP the maximum size of an ICMPv6 error message with the ICMP
extension. If the pointer is used as an offset to read the extension. If the pointer is used as an offset to read the
data in the invoking packet then a node MUST first validate data in the invoking packet, then a node MUST first validate
that the pointer value is less than the length of the Invoking that the pointer value is less than the length of the invoking
Packet data. packet data.
3.2. Usage 3.2. Usage
An ICMPv6 Destination Unreachable error with code for "headers too An ICMPv6 Destination Unreachable error with code for "Headers too
long" SHOULD be sent when a node discards a packet because the long" SHOULD be sent when a node discards a packet because the
aggregate length of headers in the packet exceeds the processing aggregate length of the headers in the packet exceeds the processing
limits of the node. The Pointer in the extended ICMPv6 structure is limits of the node. The Pointer in the extended ICMPv6 structure is
set to the offset of the first octet that exceeds the limit. set to the offset of the first octet that exceeds the limit.
This error is sent in response to a node dropping a packet because This error is sent in response to a node dropping a packet because
the aggregate header chain exceeds the processing limits of a node. the aggregate header chain exceeds the processing limits of a node.
The aggregate header chain may be composed of protocol headers other The aggregate header chain may be composed of protocol headers other
than an IPv6 header and IPv6 extension headers. For instance, in the than an IPv6 header and IPv6 extension headers. For instance, in the
case of a node parsing a UDP encapsulation protocol, the case of a node parsing a UDP encapsulation protocol, the
encapsulating UDP header would be considered to be in the aggregate encapsulating UDP header would be considered to be in the aggregate
header chain. header chain.
As noted in section 4.1, the ICMPv6 Destination Unreachable error As noted in Section 4.1, the ICMPv6 Destination Unreachable error
with code for "headers too long" has the lowest precedence of the with code for "Headers too long" has the lowest precedence of the
ICMP errors discussed in this specification. If a packet contains an ICMP errors discussed in this specification. If a packet contains an
error corresponding to a Parameter Problem code then a node SHOULD error corresponding to a Parameter Problem code, then a node SHOULD
send the Parameter Problem error instead of sending the ICMPv6 send the Parameter Problem error instead of sending the ICMPv6
Destination Unreachable error with code for "headers too long". Destination Unreachable error with code for "Headers too long".
4. Operation 4. Operation
Nodes that send or receive ICMPv6 errors due to header processing Nodes that send or receive ICMPv6 errors due to header processing
limits MUST comply with ICMPv6 processing as specified in [RFC4443]. limits MUST comply with ICMPv6 processing as specified in [RFC4443].
4.1. Priority of reporting 4.1. Priority of Reporting
More than one ICMPv6 error may be applicable to report for a packet. More than one ICMPv6 error may be applicable to report for a packet.
For instance, the number of extension headers in a packet might For instance, the number of extension headers in a packet might
exceed a limit and the aggregate length of protocol headers might exceed a limit, and the aggregate length of protocol headers might
also exceed a limit. Only one ICMPv6 error SHOULD be sent for a also exceed a limit. Only one ICMPv6 error SHOULD be sent for a
packet, so a priority is defined to determine which error to report. packet, so a priority is defined to determine which error to report.
The RECOMMENDED reporting priority of ICMPv6 errors for processing The RECOMMENDED reporting priority of ICMPv6 errors for processing
limits is from highest to lowest priority: limits is listed from highest to lowest priority:
1) Existing ICMP errors defined in [RFC4443] 1. Existing ICMP errors defined in [RFC4443].
2) "Unrecognized Next Header type encountered by intermediate 2. "Unrecognized Next Header type encountered by intermediate node"
node"
3) "Extension header too big" 3. "Extension header too big"
4) "Option too big" for length or number of consecutive padding 4. "Option too big" for length or number of consecutive padding
options exceeding a limit options exceeding a limit.
5) "Option too big" for the length of an option exceeding a limit 5. "Option too big" for the length of an option exceeding a limit.
6) "Too many options in an extension header" 6. "Too many options in an extension header"
7) "Extension header chain too long" headers exceeding a limit 7. "Extension header chain too long" headers exceeding a limit.
8) "Too many extension headers" 8. "Too many extension headers"
9) "Headers too long"
4.2. Host response 9. "Headers too long"
4.2. Host Response
When a source host receives an ICMPv6 error for a processing limit When a source host receives an ICMPv6 error for a processing limit
being exceeded, it SHOULD verify the ICMPv6 error is valid and take being exceeded, it SHOULD verify the ICMPv6 error is valid and take
appropriate action as suggested below. appropriate action as suggested below.
The general validations for ICMP as described in [RFC4443] are The general validations for ICMP as described in [RFC4443] are
applicable. The packet in the ICMP data SHOULD be validated to match applicable. The packet in the ICMP data SHOULD be validated to match
the upper layer process or connection that generated the original the upper-layer process or connection that generated the original
packet. Other validation checks that are specific to the upper packet. Other validation checks that are specific to the upper
layers may be performed and are out of the scope of this layers may be performed and are out of the scope of this
specification. specification.
The ICMPv6 error SHOULD be logged with sufficient detail for The ICMPv6 error SHOULD be logged with sufficient detail for
debugging packet loss. The details of the error, including the debugging packet loss. The details of the error, including the
addresses and the offending extension header or data, should be addresses and the offending extension header or data, should be
retained. This, for instance, would be useful for debugging when a retained. This, for instance, would be useful for debugging when a
node is mis-configured and unexpectedly discarding packets, or when a node is misconfigured and unexpectedly discarding packets or when a
new extension header is being deployed. new extension header is being deployed.
A host MAY modify its usage of protocol headers in subsequent packets A host MAY modify its usage of protocol headers in subsequent packets
to avoid repeated occurrences of the same error. to avoid repeated occurrences of the same error.
For ICMPv6 errors caused by extension header limits being exceeded: For ICMPv6 errors caused by extension header limits being exceeded:
* An error SHOULD be reported to an application if the * An error SHOULD be reported to an application if the application
application enabled extension headers for its traffic. In enabled extension headers for its traffic. In response, the
response, the application may terminate communications if application may terminate communications if extension headers are
extension headers are required, stop using extension headers in required, stop using extension headers in packets to the
packets to the destination indicated by the ICMPv6 error, or destination indicated by the ICMPv6 error, or attempt to modify
attempt to modify its use of extension headers or headers to its use of headers or extension headers to avoid further packet
avoid further packet discards. discards.
* A host system SHOULD take appropriate action if it is creating * A host system SHOULD take appropriate action if it is creating
packets with extension headers on behalf of the application. packets with extension headers on behalf of the application. If
If the offending extension header is not required for the offending extension header is not required for communication,
communication, the host may either stop sending it or otherwise the host may either stop sending it or otherwise modify its use in
modify its use in subsequent packets sent to the destination subsequent packets sent to the destination indicated in the ICMPv6
indicated in the ICMPv6 error. error.
5. Applicability and Use Cases
5. Applicability and use cases
5.1. Reliability of ICMP 5.1. Reliability of ICMP
ICMP is fundamentally an unreliable protocol and in real deployment ICMP is fundamentally an unreliable protocol and, in real deployment,
it may consistently fail over some paths. As with any other use of it may consistently fail over some paths. As with any other use of
ICMP, it is assumed that the errors defined in this document are only ICMP, it is assumed that the errors defined in this document are only
best effort to be delivered. No protocol should be implemented that the best effort to be delivered. No protocol should be implemented
relies on reliable delivery of ICMP messages. If necessary, that relies on reliable delivery of ICMP messages. If necessary,
alternative or additional mechanisms may used to augment the alternative or additional mechanisms may be employed to augment the
processes used to deduce the reason that packets are being discarded. processes used to deduce the reason that packets are being discarded.
For instance, the messages may be correlated with information For instance, ICMP error messages may be correlated with information
attained through Packetization Layer Path MTU Discovery (PLMTUD) attained through Packetization Layer Path MTU Discovery (PLPMTUD)
[RFC4821] or Happy Eyeballs for IPv6 [RFC8305]. Details of the [RFC4821] or Happy Eyeballs for IPv6 [RFC8305]. Details of the
interaction with alternative mechanisms are out of scope of this interaction with alternative mechanisms are out of scope of this
specification. specification.
5.2. Processing limits 5.2. Processing Limits
This section discusses the trends and motivations of processing This section discusses the trends and motivations of processing
limits that warrant ICMP errors. limits that warrant ICMP errors.
5.2.1. Long headers and header chains 5.2.1. Long Headers and Header Chains
The trend towards longer and more complex headers and header chains The trend towards longer and more complex headers and header chains
needing to be processed by end nodes, as well as intermediate nodes, needing to be processed by end nodes, as well as intermediate nodes,
is driven by: is driven by:
* Increasing prevalence of deep packet inspection in middleboxes. * Increasing prevalence of deep packet inspection in middleboxes.
In particular, many intermediate nodes now parse network layer In particular, many intermediate nodes now parse network-layer
encapsulation protocols or transport layer protocols. encapsulation protocols or transport-layer protocols.
* Deployment of routing headers. For instance, * Deployment of routing headers. For instance, [RFC8754] defines an
[I-D.ietf-6man-segment-routing-header] defines an extension extension header format that includes a list of IPv6 addresses
header format that includes a list of IPv6 addresses which may which may consume a considerable number of bytes.
consume a considerable number of bytes.
* Development of In-situ OAM headers that allow a rich set of * Development of in situ OAM headers that allow a rich set of
measurements to be gathered in the data path at the cost of measurements to be gathered in the data path at the cost of
additional header overhead which may be significant additional header overhead, which may be significant [OAM-IPV6].
[I-D.ioametal-ippm-6man-ioam-ipv6-options].
* Other emerging use cases of Hop-by-Hop and Destination options. * Other emerging use cases of Hop-by-Hop and Destination Options.
5.2.2. At end hosts 5.2.2. At End Hosts
End hosts may implement limits on processing extension headers as End hosts may implement limits on processing extension headers as
described in [RFC8504]. Host implementations are usually software described in [RFC8504]. Host implementations are usually software
stacks that typically don't have inherent processing limitations. stacks that typically don't have inherent processing limitations.
Limits imposed by a software stack are more likely to be for denial-
of-service mitigation or performance.
Limits imposed by a software stack are more likely to be for denial 5.2.3. At Intermediate Nodes
of service mitigation or performance.
5.2.3. At intermediate nodes
Hardware devices that process packet headers may have limits as to Hardware devices that process packet headers may have limits as to
how many headers or bytes of headers they can process. For instance, how many headers or bytes of headers they can process. For instance,
a middlebox hardware implementation might have a parsing buffer that a middlebox hardware implementation might have a parsing buffer that
contains some number of bytes of packet headers to process. Parsing contains some number of bytes of packet headers to process. Parsing
buffers typically have a fixed size such as sixty-four, 128, or 256 buffers typically have a fixed size such as 64, 128, or 256 bytes.
bytes. In addition, hardware implementations (and some software In addition, hardware implementations (and some software
implementations) often don't have loop constructs. Processing of a implementations) often don't have loop constructs. Processing of a
TLV list might be implemented as an unrolled loop so that the number TLV list might be implemented as an unrolled loop so that the number
of TLVs that can be processed is limited. of TLVs that can be processed is limited.
6. Security Considerations 6. Security Considerations
The security considerations for ICMPv6 described in [RFC4443] are The security considerations for ICMPv6 described in [RFC4443] are
applicable. The ICMP errors described in this document MAY be applicable. The ICMP errors described in this document MAY be
filtered by firewalls in accordance with [RFC4890]. filtered by firewalls in accordance with [RFC4890].
In some circumstances, the sending of ICMP errors might conceptually In some circumstances, the sending of ICMP errors might conceptually
be exploited a means to covertly deduce processing capabilities of be exploited as a means to covertly deduce the processing
nodes. As such, an implementation SHOULD allow configurable policy capabilities of nodes. Accordingly, an implementation SHOULD allow a
to withhold sending of the ICMP errors described in this configurable policy to withhold sending of the ICMP errors described
specification in environments where security of ICMP errors is a in this specification in environments where the security of ICMP
concern. errors is a concern.
7. IANA Considerations 7. IANA Considerations
7.1. Parameter Problem codes 7.1. Parameter Problem Codes
IANA is requested to assign the following codes for ICMPv6 type 4
"Parameter Problem" [IANA-PARAMPROB]:
* Unrecognized Next Header type encountered by intermediate node
(value TBA1)
* Extension header too big (value TBA2)
* Extension header chain too long (value TBA3) IANA has assigned the following codes in the "Type 4 - Parameter
Problem" registry within the ICMPv6 Parameters registry [IANA-ICMP]:
* Too many extension headers (value TBA4) +======+==================================+
| Code | Name |
+======+==================================+
| 5 | Unrecognized Next Header type |
| | encountered by intermediate node |
+------+----------------------------------+
| 6 | Extension header too big |
+------+----------------------------------+
| 7 | Extension header chain too long |
+------+----------------------------------+
| 8 | Too many extension headers |
+------+----------------------------------+
| 9 | Too many options in extension |
| | header |
+------+----------------------------------+
| 10 | Option too big |
+------+----------------------------------+
* Too many options in extension header (value TBA5) Table 2
* Option too big (value TBA6) 7.2. Destination Unreachable Codes
7.2. Destination Unreachable codes IANA has assigned the following code in the "Type 1 - Destination
Unreachable" registry within the ICMPv6 Parameters registry
[IANA-ICMP]:
IANA is requested to assign the following code for ICMPv6 type 1 +======+==================+
"Destination Unreachable" [IANA-DESTUNREACH]: | Code | Name |
+======+==================+
| 8 | Headers too long |
+------+------------------+
* Headers too long (value TBA7) Table 3
7.3. ICMP Extension Object Classes and Class Sub-types 7.3. ICMP Extension Object Classes and Class Sub-types
IANA is requested to assign the following Class value in the "ICMP IANA has assigned the following Class value in the "ICMP Extension
Extension Object Classes and Class Sub-types" registry [IANA- Object Classes and Class Sub-types" registry within the ICMP
ICMPEXT]: Parameters registry [IANA-ICMPEXT]:
* Extended information (value TBA8) +=============+======================+
| Class Value | Class Name |
+=============+======================+
| 4 | Extended Information |
+-------------+----------------------+
IANA is requested to create a Sub-type registry for the "Extended Table 4
information" ICMP extension object class. The registration procedure
for this registry shall be "Standards Action". The Sub-type value of
0 shall be reserved, values greater than zero may be assigned.
IANA is requested to assign the following Sub-type within the IANA has created a sub-type registry for the "Extended Information"
"Extended information" ICMP extension object class: ICMP extension object class. The registration procedure for this
registry is "Standards Action". The sub-type value of 0 is reserved;
values greater than zero may be assigned.
* Pointer (value TBA9) IANA has assigned the following sub-type within the "Sub-types -
Class 4 - Extended Information" registry within the ICMP Parameters
registry:
8. Acknowledgments +=======+=============+
| Value | Description |
+=======+=============+
| 1 | Pointer |
+-------+-------------+
The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard, Table 5
Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for
their comments and suggestions that improved this document.
9. References 8. References
9.1. Normative References 8.1. Normative References
[IANA-DESTUNREACH] [IANA-ICMP]
"Internet Control Message Protocol version 6 (ICMPv6) IANA, "Internet Control Message Protocol version 6
Parameters, Type 1 - Destination Unreachable", (ICMPv6) Parameters",
<https://www.iana.org/assignments/icmpv6-parameters/ <https://www.iana.org/assignments/icmpv6-parameters/>.
icmpv6-parameters.xhtml#icmpv6-parameters-codes-2>.
[IANA-ICMPEXT] [IANA-ICMPEXT]
"ICMP Extension Object Classes and Class Sub-types", IANA, "Internet Control Message Protocol (ICMP)
<https://www.iana.org/assignments/icmp-parameters/icmp- Parameters",
parameters.xhtml#icmp-parameters-ext-classes>. <https://www.iana.org/assignments/icmp-parameters/>.
[IANA-PARAMPROB]
"Internet Control Message Protocol version 6 (ICMPv6)
Parameters, Type 4 - Parameter Problem",
<https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-codes-5>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007, <https://www.rfc- DOI 10.17487/RFC4884, April 2007,
editor.org/info/rfc4884>. <https://www.rfc-editor.org/info/rfc4884>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013, <https://www.rfc- DOI 10.17487/RFC7045, December 2013,
editor.org/info/rfc7045>. <https://www.rfc-editor.org/info/rfc7045>.
[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 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc- DOI 10.17487/RFC8200, July 2017,
editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
9.2. Informative References
[I-D.ietf-6man-segment-routing-header] 8.2. Informative References
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[I-D.ioametal-ippm-6man-ioam-ipv6-options] [OAM-IPV6] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M.
"In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam- Smith, "In-situ OAM IPv6 Options", Work in Progress,
ipv6-options-02 (work in progress), March 2019. Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-03, 18
September 2020, <https://tools.ietf.org/html/draft-ietf-
ippm-ioam-ipv6-options-03>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, ICMPv6 Messages in Firewalls", RFC 4890,
DOI 10.17487/RFC4890, May 2007, <https://www.rfc- DOI 10.17487/RFC4890, May 2007,
editor.org/info/rfc4890>. <https://www.rfc-editor.org/info/rfc4890>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, <https://www.rfc- DOI 10.17487/RFC8305, December 2017,
editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
Acknowledgments
The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard,
Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for
their comments and suggestions that improved this document.
Author's Address Author's Address
Tom Herbert Tom Herbert
Intel Intel
Santa Clara, CA Santa Clara, CA
USA United States of America
Email: tom@quantonium.net Email: tom@quantonium.net
 End of changes. 145 change blocks. 
330 lines changed or deleted 362 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/