rfc8883xml2.original.xml   rfc8883.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-6man-icmp-limits-08" s
ubmissionType="IETF" >
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<title abbrev="ICMPv6 limits">ICMPv6 errors for discarding packets due to proces ipr="trust200902" number="8883" docName="draft-ietf-6man-icmp-limits-08"
sing limits</title> submissionType="IETF" obsoletes="" updates="" xml:lang="en"
<author initials='T.' surname="Herbert" fullname='Tom Herbert'> tocInclude="true" symRefs="true" sortRefs="true" version="3"
<organization>Intel</organization> consensus="true">
<address>
<postal> <front>
<street/> <title abbrev="ICMPv6 Limits">ICMPv6 Errors for Discarding Packets Due to Pr
<city>Santa Clara, CA</city> ocessing Limits</title>
<region/> <seriesInfo name="RFC" value="8883"/>
<code/> <author initials="T." surname="Herbert" fullname="Tom Herbert">
<country>USA</country> <organization>Intel</organization>
</postal> <address>
<email>tom@quantonium.net</email> <postal>
</address> <street/>
<city>Santa Clara</city>
<region>CA</region>
<code/>
<country>United States of America</country>
</postal>
<email>tom@quantonium.net</email>
</address>
</author> </author>
<date/> <date month="September" year="2020"/>
<abstract> <keyword>extension Headers</keyword>
<t> <keyword>destination Options</keyword>
<keyword>Hop-by-Hop Options</keyword>
<abstract>
<t>
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. This it cannot take action to address the cause of discarded packets. This
specification defines several new ICMPv6 errors that can be sent by a specification defines several new ICMPv6 errors that can be sent by a
node that discards packets because it is unable to process the 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.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t> <t>
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 defined limits. New ICMPv6 code points are defined to supplement those defined
in <xref target="RFC4443" />. in <xref target="RFC4443" format="default"/>.
Six of the errors are specific to processing of extension headers; Six of the errors are specific to the processing of extension headers;
another error is used when the aggregate protocol headers in a packet another error is used when the aggregate protocol headers in a packet
exceed the processing limits of a node. exceed the processing limits of a node.
</t> </t>
<section title="Extension header limits"> <section numbered="true" toc="default">
<t> <name>Extension Header Limits</name>
<t>
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 <xref target="RFC8200" />. more IPv6 extension headers <xref target="RFC8200" format="default"/>.
Extension Headers are placed 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).
</t><t> </t>
Per <xref target="RFC8200" />, except for Hop by Hop options, extension <t>
headers are not examined or processed by intermediate nodes. Many Per <xref target="RFC8200" format="default"/>, except for Hop-by-Hop Options
intermediate nodes, however, do examine extension headers for various , extension
headers are not examined or processed by intermediate nodes. However, in
deployed networks, many intermediate nodes do examine extension headers for
various
purposes. For instance, a node may examine all extension headers to purposes. For instance, a node may examine all extension headers to
locate the transport header of a packet in order to implement transport locate the transport header of a packet in order to implement transport-laye
layer filtering or to track connections to implement a stateful firewall. r filtering or to track connections to implement a stateful firewall.
</t><t> </t>
<t>
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.
</t><t> </t>
Due to the variable lengths, high maximum lengths, or potential for <t>
Denial of Service attack of extension headers, many devices impose Due to the variable lengths, high maximum lengths, or potential for a 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.
<xref target="RFC7045" /> discusses the requirements of intermediate <xref target="RFC7045" format="default"/> discusses the requirements of inte rmediate
nodes that discard packets because of unrecognized extension headers. nodes that discard packets because of unrecognized extension headers.
<xref target="RFC8504" /> discusses limits that may be applied to the <xref target="RFC8504" format="default"/> discusses limits that may be appli ed to the
number of options in Hop-by-Hop Options or Destination Options extension number of options in Hop-by-Hop Options or Destination Options extension
headers. Both intermediate nodes and end hosts may apply limits to headers. Both intermediate nodes and end hosts may apply limits to
extension header processing. When a limit is exceeded, the typical extension header processing. When a limit is exceeded, the typical
behavior is to silently discard the packet. behavior is to silently discard the packet.
</t><t> </t>
<t>
This specification defines six Parameter Problem codes that may be sent This specification defines six Parameter Problem codes that may be sent
by a node that discards a packet due to processing limits of extension by a node that discards a packet due to the processing limits of extension
headers being exceeded. The information in these ICMPv6 errors may be headers being exceeded. The information in these ICMPv6 errors may be
used for diagnostics to determine why packets are being dropped. used for diagnostics to determine why packets are being dropped.
Additionally, a source node that receives these ICMPv6 errors may be Additionally, a source node that receives these ICMPv6 errors may be
able to modify its use of extension headers in subsequent packets sent able to modify its use of extension headers in subsequent packets sent
to the destination in order to avoid further occurrences of packets being to the destination in order to avoid further occurrences of packets being
discarded. discarded.
</t> </t>
</section> </section>
<section title="Aggregate header limits"> <section numbered="true" toc="default">
<t> <name>Aggregate Header Limits</name>
<t>
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. In discard the packet or defer processing to a software slow path. 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.
</t><t> </t>
<t>
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 for processing limit. The information in this ICMPv6 error may be used for
diagnostics to determine why packets are being dropped. Additionally, a diagnostics to determine why packets are being dropped. Additionally, a
source node that receives this ICMPv6 error may be able to modify source node that receives this ICMPv6 error may be able to modify
the headers used in subsequent packets to try to avoid further the headers used in subsequent packets to try to avoid further
occurrences of packets being discarded. occurrences of packets being discarded.
</t> </t>
</section> </section>
<section title="Nonconformant packet discard"> <section numbered="true" toc="default">
<t> <name>Nonconformant Packet Discard</name>
<t>
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 any standard specification. For instance, an intermediate node of any standard specification. For instance, an intermediate node
might send a "Headers too long" code in the case that it drops a might send a "Headers too long" code in a case where it drops a
packet because it is unable to parse deep enough to extract transport packet because it is unable to parse deeply enough to extract the transport-
layer information needed for packet filtering. Such behavior might be layer information needed for packet filtering. Such behavior might be
considered nonconformant (with respect to considered nonconformant (with respect to
<xref target="RFC8200" /> for instance). <xref target="RFC8200" format="default"/>, for instance).
</t><t> </t>
<t>
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 ICMP
errors is RECOMMENDED even in cases where a node errors is <bcp14>RECOMMENDED</bcp14> even in cases where a node
might be discarding packets per a nonconformant behavior. might be discarding packets per a nonconformant behavior.
</t> </t>
</section> </section>
<section anchor="sec-definitions" numbered="true" toc="default">
<section title="Terminology" anchor="sec-definitions"> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
in <xref target="RFC2119"/>. RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</section> be interpreted as
</section> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
<section title="ICMPv6 errors for extension header limits"> when, and only when, they appear in all capitals, as shown here.
<t> </t>
</section>
</section>
<section numbered="true" toc="default">
<name>ICMPv6 Errors for Extension Header Limits</name>
<t>
Six new codes are defined for the Parameter Problem type. Six new codes are defined for the Parameter Problem type.
</t> </t>
<section title="Format"> <section numbered="true" toc="default">
<t> <name>Format</name>
The format of the ICMPv6 Parameter Problem message <xref target="RFC4443" /> <t>
The format of the ICMPv6 Parameter Problem message <xref target="RFC4443" fo
rmat="default"/>
for an extension header limit exceeded error is: for an extension header limit exceeded error is:
<figure> </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
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] |
</artwork> ]]></artwork>
</figure>
<list style="hanging"> <dl newline="true" spacing="normal">
<t hangText="IPv6 Header Fields:"> <dt>IPv6 Header Fields:</dt>
<list style="hanging">
<t hangText="Destination Address"> <dd>
<vspace /> <dl newline="true" spacing="normal">
<dt>Destination Address:</dt>
<dd>
Copied from the Source Address field of the invoking packet. Copied from the Source Address field of the invoking packet.
</t> </dd>
</list> </dl>
</t> </dd>
<t hangText="ICMPv6 Fields:">
<list style="hanging"> <dt>ICMPv6 Fields:</dt>
<t hangText="Type">
<vspace /> <dd>
4 (Parameter Problem type) <dl newline="true" spacing="normal">
<vspace /> <dt>Type:</dt>
</t> <dd>
<?rfc subcompact="yes"?> <dl>
<t hangText="Code (pertinent to this specification)"> <dt>4</dt><dd>(Parameter Problem type)</dd>
<list style="hanging" hangIndent="8"> </dl>
<t hangText="TBA1 -"> </dd>
Unrecognized Next Header type encountered by intermediate node </dl>
</t><t hangText="TBA2 -"> <dl newline="true" spacing="normal">
Extension header too big <dt>Code:</dt><dd>(pertinent to this specification)</dd>
</t><t hangText="TBA3 -"> </dl>
Extension header chain too long
</t><t hangText="TBA4 -"> <table align="center">
Too many extension headers <tbody>
</t><t hangText="TBA5 -"> <tr>
Too many options in extension header <td align="left">5</td>
</t><t hangText="TBA6 -"> <td align="left">Unrecognized Next Header type encountered
Option too big by intermediate node</td>
</t> </tr>
</list> <tr>
</t> <td align="left">6</td>
<?rfc subcompact="no"?> <td align="left">Extension header too big</td>
<t hangText="Pointer"> </tr>
<vspace /> <tr>
<td align="left">7</td>
<td align="left">Extension header chain too long</td>
</tr>
<tr>
<td align="left">8</td>
<td align="left">Too many extension headers</td>
</tr>
<tr>
<td align="left">9</td>
<td align="left">Too many options in extension header</td>
</tr>
<tr>
<td align="left">10</td>
<td align="left">Option too big</td>
</tr>
</tbody>
</table>
<dl newline="true" spacing="normal">
<dt>Pointer:</dt>
<dd>
<t>
Identifies the octet offset within the invoking packet where Identifies the octet offset within the invoking packet where
the problem occurred. the problem occurred.
<vspace blankLines="1" /> </t>
The pointer will point beyond the end of the Invoking Packet if <t>
The pointer will point beyond the end of the IPv6 packet if
the field exceeding the limit is beyond what can fit in the the field exceeding the limit is beyond what can fit in the
maximum size of an ICMPv6 error message extension. If the maximum size of an ICMPv6 error message. If the
pointer is used as an offset to read the data in the invoking pointer is used as an offset to read the data in the invoking
packet then a node MUST first validate that the pointer value packet, then a node <bcp14>MUST</bcp14> first validate that the poin
is less than the length of the Invoking Packet data. ter value
</t> is less than the length of the invoking packet data.
</list> </t>
</t> </dd>
</list> </dl>
</t> </dd>
</section> </dl>
<section title="Unrecognized Next Header type encountered by intermediate node (
code TBA1)"> </section>
<t> <section numbered="true" toc="default">
This code SHOULD be sent by an intermediate node that discards a <name>Unrecognized Next Header Type Encountered by Intermediate Node (Co
de 5)</name>
<t>
This code <bcp14>SHOULD</bcp14> be sent by an intermediate node that discard
s 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 the its examination. The ICMPv6 Pointer field is set to the offset of the
unrecognized next header value within the original packet. unrecognized Next Header value within the original packet.
</t><t> </t>
Note that this code is sent by intermediate nodes, and <t>
SHOULD NOT be sent by a final destination. If a final destination Note that this code is sent by intermediate nodes and
node observes an unrecognized header then it SHOULD send an ICMP Parameter <bcp14>SHOULD NOT</bcp14> be sent by a final destination. If a final destina
tion
node observes an unrecognized header, then it <bcp14>SHOULD</bcp14> send an
ICMP Parameter
Problem message with an ICMP Code value of 1 ("unrecognized Next Header Problem message with an ICMP Code value of 1 ("unrecognized Next Header
type encountered") as specified in <xref target="RFC8200" />. type encountered") as specified in <xref target="RFC8200" format="default"/>
</t> .
</section> </t>
<section title="Extension header too big (code TBA2)"> </section>
<t> <section numbered="true" toc="default">
An ICMPv6 Parameter Problem with code for "extension header too big" <name>Extension Header Too Big (Code 6)</name>
SHOULD be sent when a node discards a packet because the size of an <t>
An ICMPv6 Parameter Problem with code for "Extension header too big"
<bcp14>SHOULD</bcp14> 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.
</t> </t>
</section> </section>
<section title="Extension header chain too long (code TBA3)"> <section numbered="true" toc="default">
<t> <name>Extension Header Chain Too Long (Code 7)</name>
An ICMPv6 Parameter Problem with code for "extension header chain too <t>
long" SHOULD be sent when a node discards a packet with an extension An ICMPv6 Parameter Problem with code for "Extension header chain too
long" <bcp14>SHOULD</bcp14> be sent when a node discards a packet with an ex
tension
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 the
limit. limit.
</t> </t>
</section> </section>
<section title="Too many extension headers (code TBA4)"> <section numbered="true" toc="default">
<t> <name>Too Many Extension Headers (Code 8)</name>
An ICMPv6 Parameter Problem with code for "too many extension headers" <t>
SHOULD be sent when a node discards a packet with an extension An ICMPv6 Parameter Problem with code for "Too many extension headers"
<bcp14>SHOULD</bcp14> be sent when a node discards a packet with an extensio
n
header chain that exceeds a limit on the number of extension headers header chain that exceeds a limit on the number of extension headers
in the chain. The ICMPv6 Pointer is set to the offset of first octet of in the chain. The ICMPv6 Pointer is set to the offset of the first octet of
the first extension header that is beyond the limit. the first extension header that is beyond the limit.
</t> </t>
</section> </section>
<section title="Too many options in extension header (code TBA5)"> <section numbered="true" toc="default">
<t> <name>Too Many Options in Extension Header (Code 9)</name>
An ICMPv6 Parameter Problem with code for "too many options in <t>
extension header" SHOULD be sent when a node discards a packet with An ICMPv6 Parameter Problem with code for "Too many options in
extension header" <bcp14>SHOULD</bcp14> be sent when a node discards a packe
t with
an extension header that has a number of options that exceeds 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.
</t> </t>
</section> </section>
<section title="Option too big (code TBA6)"> <section numbered="true" toc="default">
<t> <name>Option Too Big (Code 10)</name>
An ICMPv6 Parameter Problem with code for "option too big" is sent in <t>
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.
<list style="hanging"> </t>
<t hangText="Possible limits related to padding include:"> <t>Possible limits related to padding include:</t>
<list style="hanging"> <ul spacing="normal" empty="false">
<t hangText="*"> <li>
The number of consecutive PAD1 options in destination The number of consecutive PAD1 options in Destination
options or hop-by-hop options is limited to seven octets Options or Hop-by-Hop Options is limited to seven octets
<xref target="RFC8504" />. <xref target="RFC8504" format="default"/>.
</t><t hangText="*"> </li>
The length of PADN options in destination options or <li>
hop-by-hop options is limited seven octets The length of PADN options in Destination Options or
<xref target="RFC8504" />. Hop-by-Hop Options is limited seven octets
</t><t hangText="*"> <xref target="RFC8504" format="default"/>.
</li>
<li>
The aggregate length of a set of consecutive PAD1 or PADN The aggregate length of a set of consecutive PAD1 or PADN
options in destination options or hop-by-hop options is options in Destination Options or Hop-by-Hop Options is
limited to seven octets. limited to seven octets.
</t> </li>
</list> </ul>
</t> </section>
</list> </section>
</t> <section numbered="true" toc="default">
</section> <name>ICMPv6 Error for Aggregate Header Limits</name>
</section> <t>
<section title="ICMPv6 error for aggregate header limits"> One code is defined for the Destination Unreachable type for aggregate
<t>
One code is defined for Destination Unreachable type for aggregate
header limits. header limits.
</t><t> </t>
<t>
This ICMP error may be applied to other headers in a packet This ICMP error may be applied to other headers in a packet
than just the IPv6 header or IPv6 extension headers. Therefore, than just the IPv6 header or IPv6 extension headers. Therefore,
a Destination Unreachable type with a multi-part ICMPv6 message a Destination Unreachable type with a multi-part ICMPv6 message
format is used in lieu of the Parameter Problem type which only format is used in lieu of the Parameter Problem type, which only
indicates errors concerning IPv6 headers. indicates errors concerning IPv6 headers.
</t> </t>
<section title="Format"> <section numbered="true" toc="default">
<t> <name>Format</name>
<t>
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 <xref target="RFC4884" />. message format as defined in <xref target="RFC4884" format="default"/>.
The extension object class "Extended Information" is defined to The extension object class "Extended Information" is defined to
contain objects for ancillary information pertaining to an ICMP contain objects for ancillary information pertaining to an ICMP
Destination Unreachable error. Within this object class, the sub-type Destination Unreachable error. Within this object class, the sub-type
"Pointer" is defined which contains Pointer field with similar semantics "Pointer" is defined, which contains a Pointer field with similar
to the Pointer field in ICMP Parameter Problem errors. semantics to the Pointer field in ICMP Parameter Problem errors.
</t><t> </t>
<t>
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:
<figure> </t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
</artwork> ]]></artwork>
</figure> <dl newline="true" spacing="normal">
<dt>IPv6 Header Fields:</dt>
<list style="hanging"> <dd>
<t hangText="IPv6 Header Fields:"> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>Destination Address:</dt>
<t hangText="Destination Address"> <dd>
<vspace />
Copied from the Source Address field of the invoking packet. Copied from the Source Address field of the invoking packet.
</t> </dd>
</list> </dl>
</t> </dd>
<t hangText="ICMPv6 Fields:"> <dt>ICMPv6 Fields:</dt>
<list style="hanging"> <dd>
<t hangText="Type"> <dl newline="true" spacing="normal">
<vspace /> <dt>Type:</dt>
1 - Destination Unreachable type <dd>
</t> <dl><dt>1 -</dt><dd>Destination Unreachable</dd>
<t hangText="Code (pertinent to this specification)"> </dl>
<vspace /> </dd>
TBA7 - Headers too long <dt>Code: (pertinent to this specification)</dt>
</t> <dd>
<t hangText="Length"> <dl>
<vspace /> <dt>8 -</dt><dd>Headers too long</dd></dl></dd>
Length of the padded Invoking Packet measured in 64-bit words. <dt>Length:</dt>
<dd>Length of the padded invoking packet data measured in 64-bit w
ords.
The ICMP extension structure immediately follows the padded The ICMP extension structure immediately follows the padded
Invoking Packet invoking packet data.</dd>
</t> <dt>Invoking Packet:</dt>
<t hangText="Invoking Packet"> <dd>Contains as much of the invoking packet as possible without th
<vspace /> e
Contains as much of 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 data <bcp14>MUST</bcp14> be zero padded to the nearest 64-bit b
Packet MUST be zero padded to the nearest 64-bit boundary oundary
<xref target="RFC4884" />. <xref target="RFC4884" format="default"/>.
If the original invoking packet did not contain 128 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 <bcp14>MUST</bcp14> be zero padded to
</t> 128 octets.</dd>
</list> </dl>
</t> </dd>
<t hangText="ICMP Extension Fields:"> <dt>ICMP Extension Fields:</dt>
<list style="hanging"> <dd>
<t hangText="Version"> <dl newline="true" spacing="normal">
<vspace /> <dt>Version:</dt>
2 - per <xref target="RFC4884" /> <dd>
</t> <dl>
<t hangText="Reserved"> <dt>2 -</dt><dd>per <xref target="RFC4884"
<vspace /> format="default"/></dd>
0</t> </dl></dd>
<t hangText="Checksum"> <dt>Reserved:</dt>
<vspace /> <dd>0</dd>
The one's complement checksum of the ICMP extension <dt>Checksum:</dt>
<xref target="RFC4884" /> <dd>The one's complement checksum of the ICMP extension
</t><t hangText="Length"> <xref target="RFC4884" format="default"/></dd>
<vspace /> <dt>Length:</dt>
8 - length of the object header and Pointer field <dd>
</t><t hangText="Class-Num"> <dl>
<vspace /> <dt>8 -</dt><dd>length of the object header and Pointer
TBA8 - Extended Information class field</dd>
</t><t hangText="C-Type"> </dl></dd>
<vspace /> <dt>Class-Num:</dt>
TBA9 - Pointer sub-type <dd>
</t><t hangText="Pointer"> <dl>
<vspace /> <dt>4 -</dt><dd>Extended Information</dd>
Identifies the octet offset within the invoking packet </dl></dd>
where a limit was exceeded. <dt>C-Type:</dt>
<vspace blankLines="1" /> <dd>
The pointer will point beyond the end of the Invoking Packet if <dl>
<dt>1 -</dt><dd>Pointer</dd>
</dl></dd>
<dt>Pointer:</dt>
<dd><t>Identifies the octet offset within the invoking packet
where a limit was exceeded.</t>
<t>The pointer will point beyond the end of the invoking packet data i
f
the field exceeding the limit is beyond what can fit in the the field exceeding the limit is beyond what can fit in the
maximum size of an ICMPv6 error message with the ICMP maximum size of an ICMPv6 error message with the ICMP
extension. If the pointer is used as an offset to read the data extension. If the pointer is used as an offset to read the data
in the invoking packet then a node MUST first validate in the invoking packet, then a node <bcp14>MUST</bcp14> 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.</t>
</t> </dd>
</list> </dl>
</t> </dd>
</list> </dl>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="Usage"> <name>Usage</name>
<t> <t>
An ICMPv6 Destination Unreachable error with code for "headers An ICMPv6 Destination Unreachable error with code for "Headers
too long" SHOULD be sent when a node discards a packet because too long" <bcp14>SHOULD</bcp14> be sent when a node discards a packet becaus
the aggregate length of headers in the packet exceeds the e
the aggregate length of the headers in the packet exceeds the
processing limits of the node. The Pointer in the extended processing limits of the node. The Pointer in the extended
ICMPv6 structure is set to the offset of the first octet that ICMPv6 structure is set to the offset of the first octet that
exceeds the limit. exceeds the limit.
</t><t> </t>
<t>
This error is sent in response to a node dropping a packet This error is sent in response to a node dropping a packet
because the aggregate header chain exceeds the processing because the aggregate header chain exceeds the processing
limits of a node. The aggregate header chain may be composed of limits of a node. The aggregate header chain may be composed of
protocol headers other than an IPv6 header and IPv6 extension protocol headers other than an IPv6 header and IPv6 extension
headers. For instance, in the case of a node parsing a UDP headers. For instance, in the case of a node parsing a UDP
encapsulation protocol, the encapsulating UDP header would be encapsulation protocol, the encapsulating UDP header would be
considered to be in the aggregate header chain. considered to be in the aggregate header chain.
</t><t> </t>
As noted in section 4.1, the ICMPv6 Destination Unreachable <t>
error with code for "headers too long" has the lowest As noted in <xref target="priority"/>, the ICMPv6 Destination Unreachable
error with code for "Headers too long" has the lowest
precedence of the ICMP errors discussed in this specification. precedence of the ICMP errors discussed in this specification.
If a packet contains an error corresponding to a Parameter If a packet contains an error corresponding to a Parameter
Problem code then a node SHOULD send the Parameter Problem Problem code, then a node <bcp14>SHOULD</bcp14> send the Parameter Problem
error instead of sending the ICMPv6 Destination Unreachable error instead of sending the ICMPv6 Destination Unreachable
error with code for "headers too long". error with code for "Headers too long".
</t> </t>
</section> </section>
</section> </section>
<section title="Operation"> <section numbered="true" toc="default">
<t> <name>Operation</name>
<t>
Nodes that send or receive ICMPv6 errors due to header Nodes that send or receive ICMPv6 errors due to header
processing limits MUST comply with ICMPv6 processing as processing limits <bcp14>MUST</bcp14> comply with ICMPv6 processing as
specified in <xref target="RFC4443" />. specified in <xref target="RFC4443" format="default"/>.
</t> </t>
<section title="Priority of reporting"> <section anchor="priority" numbered="true" toc="default">
<t> <name>Priority of Reporting</name>
<t>
More than one ICMPv6 error may be applicable to report for a More than one ICMPv6 error may be applicable to report for a
packet. For instance, the number of extension headers in a packet. For instance, the number of extension headers in a
packet might exceed a limit and the aggregate length of packet might exceed a limit, and the aggregate length of
protocol headers might also exceed a limit. Only one ICMPv6 protocol headers might also exceed a limit. Only one ICMPv6
error SHOULD be sent for a packet, so a priority is defined to error <bcp14>SHOULD</bcp14> be sent for a packet, so a priority is defined t o
determine which error to report. determine which error to report.
<list style="hanging"> </t>
<t hangText="The RECOMMENDED reporting priority of ICMPv6 errors for proce <t>The <bcp14>RECOMMENDED</bcp14> reporting priority of ICMPv6 errors for
ssing limits is from highest to lowest priority:"> processing limits is listed from highest to lowest priority:</t>
<list style="hanging"> <ol spacing="normal">
<t hangText="1)"> <li>
Existing ICMP errors defined in <xref target="RFC4443" /> Existing ICMP errors defined in <xref target="RFC4443" format="defau
</t><t hangText="2)"> lt"/>.
</li>
<li>
"Unrecognized Next Header type encountered by intermediate node" "Unrecognized Next Header type encountered by intermediate node"
</t><t hangText="3)"> </li>
<li>
"Extension header too big" "Extension header too big"
</t><t hangText="4)"> </li>
<li>
"Option too big" for length or number of consecutive padding "Option too big" for length or number of consecutive padding
options exceeding a limit options exceeding a limit.
</t><t hangText="5)"> </li>
"Option too big" for the length of an option exceeding a limit <li>
</t><t hangText="6)"> "Option too big" for the length of an option exceeding a limit.
</li>
<li>
"Too many options in an extension header" "Too many options in an extension header"
</t><t hangText="7)"> </li>
<li>
"Extension header chain too long" "Extension header chain too long"
headers exceeding a limit headers exceeding a limit.
</t><t hangText="8)"> </li>
<li>
"Too many extension headers" "Too many extension headers"
</t><t hangText="9)"> </li>
<li>
"Headers too long" "Headers too long"
</t> </li>
</list> </ol>
</t> </section>
</list> <section numbered="true" toc="default">
</t> <name>Host Response</name>
</section> <t>
<section title="Host response">
<t>
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 <bcp14>SHOULD</bcp14> verify the ICMPv6 error is valid an d take
appropriate action as suggested below. appropriate action as suggested below.
</t><t> </t>
<t>
The general validations for ICMP as described in The general validations for ICMP as described in
<xref target="RFC4443" /> are applicable. The packet in the ICMP data <xref target="RFC4443" format="default"/> are applicable. The packet in the
SHOULD be validated to match the upper layer process or connection that ICMP data
<bcp14>SHOULD</bcp14> be validated to match the upper-layer process or conne
ction that
generated the original packet. Other validation checks that are specific generated the original packet. Other validation checks that are specific
to the upper layers may be performed and are out of the scope of this to the upper layers may be performed and are out of the scope of this
specification. specification.
</t><t> </t>
The ICMPv6 error SHOULD be logged with sufficient detail for <t>
The ICMPv6 error <bcp14>SHOULD</bcp14> 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.
</t><t> </t>
A host MAY modify its usage of protocol headers in subsequent packets <t>
A host <bcp14>MAY</bcp14> 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.
<list style="hanging"> </t>
<t hangText="For ICMPv6 errors caused by extension header limits being exc <t>For ICMPv6 errors caused by extension header limits being exceeded:
eeded:"> </t>
<list style="hanging"> <ul empty="false" spacing="normal">
<t hangText="*"> <li>
An error SHOULD be reported to an application if the application An error <bcp14>SHOULD</bcp14> be reported to an application if
enabled extension headers for its traffic. In response, the the application enabled extension headers for its traffic. In
application may terminate communications if extension headers response, the application may terminate communications if extension h
eaders
are required, stop using extension headers in packets to the are required, stop using extension headers in packets to the
destination indicated by the ICMPv6 error, or attempt to modify destination indicated by the ICMPv6 error, or attempt to modify
its use of extension headers or headers to avoid further packet its use of headers or extension headers to avoid further packet
discards. discards.
</t> </li>
<t hangText="*"> <li>
A host system SHOULD take appropriate action if it is creating A host system <bcp14>SHOULD</bcp14> take appropriate action if it is
creating
packets with extension headers on behalf of the application. If packets with extension headers on behalf of the application. If
the offending extension header is not required for the offending extension header is not required for
communication, the host may either stop sending it or otherwise communication, the host may either stop sending it or otherwise
modify its use in subsequent packets sent to the destination modify its use in subsequent packets sent to the destination
indicated in the ICMPv6 error. indicated in the ICMPv6 error.
</t> </li>
</list> </ul>
</t> </section>
</list> </section>
</t> <section numbered="true" toc="default">
</section> <name>Applicability and Use Cases</name>
</section> <section numbered="true" toc="default">
<section title="Applicability and use cases"> <name>Reliability of ICMP</name>
<t>
<section title="Reliability of ICMP"> ICMP is fundamentally an unreliable protocol and, in real deployment,
<t>
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 that
relies on reliable delivery of ICMP messages. If necessary, 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 processes used to deduce the reason that packets are being
discarded. For instance, ICMP error messages may be correlated with discarded. For instance, ICMP error messages may be correlated with
information attained through Packetization Layer Path MTU Discovery information attained through Packetization Layer Path MTU Discovery
(PLMTUD) <xref target="RFC4821" /> or Happy Eyeballs for IPv6 (PLPMTUD) <xref target="RFC4821" format="default"/> or Happy Eyeballs for IP
<xref target="RFC8305" />. Details of the v6
<xref target="RFC8305" format="default"/>. 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.
</t> </t>
</section> </section>
<section title="Processing limits"> <section numbered="true" toc="default">
<t> <name>Processing Limits</name>
<t>
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.
</t> </t>
<section title="Long headers and header chains"> <section numbered="true" toc="default">
<t> <name>Long Headers and Header Chains</name>
<list style="hanging"> <t>The trend towards longer and more complex headers and header chai
<t hangText="The trend towards longer and more complex headers and header ns needing to be processed by end nodes, as well as intermediate nodes, is drive
chains needing to be processed by end nodes, as well as intermediate nodes, n by:</t>
is driven by:"> <ul empty="false" spacing="normal">
<list style="hanging"> <li>
<t hangText="*">
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.
</t><t hangText="*"> </li>
<li>
Deployment of routing headers. For instance, Deployment of routing headers. For instance,
<xref target="I-D.ietf-6man-segment-routing-header" /> defines an <xref target="RFC8754" format="default"/> defines an
extension header format that includes a list of IPv6 addresses extension header format that includes a list of IPv6 addresses
which may consume a considerable number of bytes. which may consume a considerable number of bytes.
</t><t hangText="*"> </li>
Development of In-situ OAM headers that allow a rich set of <li>
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 <xref target="I
<xref target="I-D.ioametal-ippm-6man-ioam-ipv6-options" />. -D.ietf-ippm-ioam-ipv6-options" format="default"/>.
</t><t hangText="*"> </li>
Other emerging use cases of Hop-by-Hop and Destination options. <li>
</t> Other emerging use cases of Hop-by-Hop and Destination Options.
</list> </li>
</t> </ul>
</list> </section>
</t> <section numbered="true" toc="default">
</section> <name>At End Hosts</name>
<section title="At end hosts"> <t>
<t>
End hosts may implement limits on processing extension headers as End hosts may implement limits on processing extension headers as
described in <xref target="RFC8504" />. Host implementations are usually described in <xref target="RFC8504" format="default"/>. Host implementations are usually
software stacks that typically don't have inherent processing limitations. software stacks that typically don't have inherent processing limitations.
Limits imposed by a software stack are more likely to be for denial Limits imposed by a software stack are more likely to be for denial-of-servi
of service mitigation or performance. ce mitigation or performance.
</t> </t>
</section> </section>
<section title="At intermediate nodes"> <section numbered="true" toc="default">
<t> <name>At Intermediate Nodes</name>
<t>
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. In addition, hardware implementations (and some software bytes. 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.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<t> <name>Security Considerations</name>
<t>
The security considerations for ICMPv6 described in The security considerations for ICMPv6 described in
<xref target="RFC4443" /> are applicable. The ICMP errors described <xref target="RFC4443" format="default"/> are applicable. The ICMP errors de
in this document MAY be filtered by firewalls in accordance with scribed
<xref target="RFC4890" />. in this document <bcp14>MAY</bcp14> be filtered by firewalls in accordance w
</t><t> ith
<xref target="RFC4890" format="default"/>.
</t>
<t>
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 capabilities of
nodes. Accordingly, an implementation SHOULD allow configurable policy to nodes. Accordingly, an implementation <bcp14>SHOULD</bcp14> allow a configur
able policy to
withhold sending of the ICMP errors described in this specification in withhold sending of the ICMP errors described in this specification in
environments where security of ICMP errors is a concern. environments where the security of ICMP errors is a concern.
</t>
</section>
<section title="IANA Considerations">
<section title="Parameter Problem codes">
<t>
<list style="hanging">
<t hangText="IANA is requested to assign the following codes for ICMPv6 ty
pe 4 &quot;Parameter Problem&quot; [IANA-PARAMPROB]:">
<list style="hanging">
<t hangText="*">Unrecognized Next Header type encountered by intermedi
ate node (value TBA1)</t>
<t hangText="*">Extension header too big (value TBA2)</t>
<t hangText="*">Extension header chain too long (value TBA3)</t>
<t hangText="*">Too many extension headers (value TBA4)</t>
<t hangText="*">Too many options in extension header (value TBA5)</t>
<t hangText="*">Option too big (value TBA6)</t>
</list>
</t>
</list>
</t>
</section>
<section title="Destination Unreachable codes">
<t>
<list style="hanging">
<t hangText="IANA is requested to assign the following code for ICMPv6 typ
e 1 &quot;Destination Unreachable&quot; [IANA-DESTUNREACH]:">
<list style="hanging">
<t hangText="*">Headers too long (value TBA7)</t>
</list>
</t>
</list>
</t>
</section>
<section title="ICMP Extension Object Classes and Class Sub-types">
<t>
<list style="hanging">
<t hangText="IANA is requested to assign the following Class value in the
&quot;ICMP Extension Object Classes and Class Sub-types&quot; registry [IANA-ICM
PEXT]:">
<list style="hanging">
<t hangText="*">Extended information (value TBA8)</t>
</list>
</t>
</list>
</t><t>
IANA is requested to create a Sub-type registry for the "Extended
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.
</t>
<t>
<list style="hanging">
<t hangText="IANA is requested to assign the following Sub-type within the
&quot;Extended information&quot; ICMP extension object class:">
<list style="hanging">
<t hangText="*">Pointer (value TBA9)</t>
</list>
</t> </t>
</list> </section>
</t> <section numbered="true" toc="default">
</section> <name>IANA Considerations</name>
</section> <section numbered="true" toc="default">
<section title="Acknowledgments"> <name>Parameter Problem Codes</name>
<t> <t>IANA has assigned the following codes in the "Type 4 - Parameter
The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard, Problem" registry within the ICMPv6 Parameters registry <xref target="I
Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for ANA-ICMP"/>:</t>
their comments and suggestions that improved this document.
</t>
</section>
</middle> <table anchor="param-prob">
<thead>
<tr>
<th>Code</th>
<th>Name</th>
</tr>
</thead>
<tbody>
<tr>
<td>5</td>
<td>Unrecognized Next Header type encountered by intermediate node</td>
</tr>
<tr>
<td>6</td>
<td>Extension header too big</td>
</tr>
<tr>
<td>7</td>
<td>Extension header chain too long</td>
</tr>
<tr>
<td>8</td>
<td>Too many extension headers</td>
</tr>
<tr>
<td>9</td>
<td>Too many options in extension header</td>
</tr>
<tr>
<td>10</td>
<td>Option too big</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Destination Unreachable Codes</name>
<t>IANA has assigned the following code in the "Type 1 - Destination
Unreachable" registry within the ICMPv6 Parameters registry <xref targe
t="IANA-ICMP"/>:</t>
<?rfc needLines="20"?> <table anchor="dest-unreach">
<back> <thead>
<references title="Normative References"> <tr>
<?rfc include="reference.RFC.2119"?> <th>Code</th>
<?rfc include="reference.RFC.4443"?> <th>Name</th>
<?rfc include="reference.RFC.8200"?> </tr>
<?rfc include="reference.RFC.7045"?> </thead>
<?rfc include="reference.RFC.4884"?> <tbody>
<reference anchor="IANA-PARAMPROB" target="https://www.iana.org/assignments/ic <tr>
mpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-5"> <td>8</td>
<front> <td>Headers too long</td>
<title>Internet Control Message Protocol version 6 (ICMPv6) Parameters, Ty </tr>
pe 4 - Parameter Problem</title> </tbody>
<author/> </table>
<date/> </section>
</front> <section numbered="true" toc="default">
</reference> <name>ICMP Extension Object Classes and Class Sub-types</name>
<reference anchor="IANA-DESTUNREACH" target="https://www.iana.org/assignments/ <t>IANA has assigned the following Class value in
icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-2"> the "ICMP Extension Object Classes and Class Sub-types"
<front> registry within the ICMP Parameters registry <xref target="IANA-ICMPEXT
<title>Internet Control Message Protocol version 6 (ICMPv6) Parameters, Ty "/>:</t>
pe 1 - Destination Unreachable</title> <table anchor="class-sub-types">
<author/> <thead>
<date/> <tr>
</front> <th>Class Value</th>
</reference> <th>Class Name</th>
<reference anchor="IANA-ICMPEXT" target="https://www.iana.org/assignments/icmp </tr>
-parameters/icmp-parameters.xhtml#icmp-parameters-ext-classes"> </thead>
<front> <tbody>
<title>ICMP Extension Object Classes and Class Sub-types</title> <tr>
<author/> <td>4</td>
<date/> <td>Extended Information</td>
</front> </tr>
</reference> </tbody>
</references> </table>
<t>
IANA has created a sub-type registry for the "Extended
Information" 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.
</t>
<t>IANA has assigned the following sub-type within the "Sub-types —
Class 4 — Extended Information" registry within the ICMP Parameters reg
istry:</t>
<references title="Informative References"> <table anchor="extended-info">
<?rfc include="reference.RFC.8504"?> <thead>
<?rfc include="reference.RFC.4890"?> <tr>
<?rfc include="reference.RFC.4821"?> <th>Value</th>
<?rfc include="reference.RFC.8305"?> <th>Description</th>
<?rfc include="reference.I-D.draft-ietf-6man-segment-routing-header-26.xml"?> </tr>
<?rfc include="reference.I-D.draft-ioametal-ippm-6man-ioam-ipv6-options-02.xml </thead>
"?> <tbody>
</references> <tr>
<td>1</td>
<td>Pointer</td>
</tr>
</tbody>
</table>
</back> </section>
</section>
</middle>
<back>
</rfc> <displayreference target="I-D.ietf-ippm-ioam-ipv6-options" to="OAM-IPV6"/>
<!-- Local Variables: --> <references>
<!-- fill-column:72 --> <name>References</name>
<!-- End: --> <references>
<name>Normative References</name>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.x
ml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8200.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7045.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4884.xml"/>
<reference anchor="IANA-ICMP" target="https://www.iana.org/assignments/i
cmpv6-parameters/">
<front>
<title>Internet Control Message Protocol version 6 (ICMPv6) Paramete
rs</title>
<author><organization>IANA</organization></author>
</front>
</reference>
<reference anchor="IANA-ICMPEXT" target="https://www.iana.org/assignment
s/icmp-parameters/">
<front>
<title>Internet Control Message Protocol (ICMP) Parameters</title>
<author><organization>IANA</organization></author>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8504.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4890.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4821.xml"/>
<xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8305.x
ml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8754.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-ippm-ioam-ipv6-options.xml"/>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>
The author would like to thank <contact fullname="Ron Bonica"/>,
<contact fullname="Bob Hinden"/>, <contact fullname="Nick Hilliard"/>,
<contact fullname="Michael Richardson"/>, <contact fullname="Mark Smith"/>,
<contact fullname="Suresh Krishnan"/>, and <contact fullname="Ole Tran"/> for
their comments and suggestions that improved this document.
</t>
</section>
</back>
</rfc>
 End of changes. 114 change blocks. 
560 lines changed or deleted 658 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/