< draft-ietf-6man-icmp-limits-03.txt   draft-ietf-6man-icmp-limits-04.txt >
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Standard Quantonium Intended Status: Standard Intel
Expires: November 2019 Expires: February 2020
May 29, 2019 August 6, 2019
ICMPv6 errors for discarding packets due to processing limits ICMPv6 errors for discarding packets due to processing limits
draft-ietf-6man-icmp-limits-03 draft-ietf-6man-icmp-limits-04
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. This it cannot take action to address the cause of discarded packets. This
document defines ICMPv6 errors that can be sent by a node that specification defines ICMPv6 errors that can be sent by a node that
discards packets because it is unable to process the protocol discards packets because it is unable to process the protocol
headers. A node that receives such an ICMPv6 error may be able to headers. A node that receives such an ICMPv6 error may be able to
modify what it sends in future packets to avoid subsequent packet modify what it sends in future packets to avoid subsequent packet
discards. discards.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Extension header limits . . . . . . . . . . . . . . . . . . 3 1.1 Extension header limits . . . . . . . . . . . . . . . . . . 4
1.2 Aggregate header limits . . . . . . . . . . . . . . . . . . 4 1.2 Aggregate header limits . . . . . . . . . . . . . . . . . . 5
2 ICMPv6 errors for extension header limits . . . . . . . . . . . 4 2 ICMPv6 errors for extension header limits . . . . . . . . . . . 5
2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Unrecognized Next Header type encountered (code 1) . . . . . 5 2.2 Unrecognized Next Header type encountered (code 1) . . . . . 6
2.3 Extension header too big (code 4) . . . . . . . . . . . . . 5 2.3 Extension header too big (code 4) . . . . . . . . . . . . . 6
2.4 Extension header chain too long (code 5) . . . . . . . . . . 6 2.4 Extension header chain too long (code 5) . . . . . . . . . . 7
2.5 Too many options in extension header (code 6) . . . . . . . 6 2.5 Too many options in extension header (code 6) . . . . . . . 7
2.6 Option too big (code 7) . . . . . . . . . . . . . . . . . . 6 2.6 Option too big (code 7) . . . . . . . . . . . . . . . . . . 7
3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 7 3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 8
3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 8 4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 9
4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 10
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 5 Applicability and use cases . . . . . . . . . . . . . . . . . . 11
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Nonconformant packet discard . . . . . . . . . . . . . . . . 11
6.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 11 5.2 Reliability of ICMP . . . . . . . . . . . . . . . . . . . . 11
6.2 Destination Unreachable codes . . . . . . . . . . . . . . . 11 5.3 Processing limits . . . . . . . . . . . . . . . . . . . . . 11
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.1 Long headers and header chains . . . . . . . . . . . . . 11
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.2 At end nodes . . . . . . . . . . . . . . . . . . . . . . 12
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 5.3.3 At intermediate nodes . . . . . . . . . . . . . . . . . 12
8.2 Informative References . . . . . . . . . . . . . . . . . . 12 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
7.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 14
7.2 Destination Unreachable codes . . . . . . . . . . . . . . . 14
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1 Normative References . . . . . . . . . . . . . . . . . . . 14
9.2 Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Introduction 1 Introduction
This document specifies ICMPv6 errors that can be sent when a node This document specifies ICMPv6 errors that can be sent when a node
discards a packet due to it being unable to process the necessary discards a packet due to it being unable to process the necessary
protocol headers because of processing constraints or limits. New protocol headers because of processing constraints or limits. New
ICMPv6 code points are defined as an update to [RFC4443]. Five of the ICMPv6 code points are defined as an update to [RFC4443]. Five of the
errors are specific to processing limits of extension headers; errors are specific to processing of extension headers; another error
another error is used when the aggregate protocol headers in a packet is used when the aggregate protocol headers in a packet exceed the
exceed the processing limits of a node. 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 length of 2048 octets and must fit into extension headers may have a length of 2048 octets and must fit into
one MTU. Destination Options and Hop-by-Hop Options contain a list of one MTU. Destination Options and Hop-by-Hop Options contain a list of
options in Type-length-value (TLV) format. Each option includes a options in Type-length-value (TLV) format. Each option includes a
length of the data field in octets: the minimum size of an option length of the data field in octets: the minimum size of an option
(non-pad type) is two octets and the maximum size is 257 octets. The (non-pad type) is two octets and the maximum size is 257 octets. The
number of options in an extension header is only limited by the number of options in an extension header is only limited by the
length of the extension header and MTU. Options may also be skipped length of the extension header and MTU. Options may be skipped over
over by a receiver if they are unknown and the Option Type indicates by a receiver if they are unknown and the Option Type indicates to
to skip (first two high order bits are 00). skip (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. Many intermediate
nodes, however, do examine extension header for various purposes. For nodes, however, do examine extension header for various purposes. For
instance, a node may examine all extension headers to locate the instance, a node may examine all extension headers to locate the
transport header of a packet in order to implement transport layer transport header of a packet in order to implement transport layer
filtering or to track connections to implement a stateful firewall. 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
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 or Destination Options extension headers. When a limit is by-Hop or Destination Options extension headers. Both intermediate
exceeded, the typical behavior is to silently discard a packet. Both nodes and end hosts may apply limits to extension header processing.
intermediate nodes and end hosts may implement limits to extension When a limit is exceeded, the typical behavior is to silently discard
header processing. the packet.
This document defines four Parameter Problem codes and extends the This specification defines four Parameter Problem codes and extends
applicably of an existing code that may be sent by a node that the applicably of an existing code that may be sent by a node that
discards a packet due to processing limits of extension headers being discards a packet due to processing limits of extension headers being
exceeded. A source host that receives an ICMPv6 error can modify its exceeded. A source host that receives an ICMPv6 error may modify its
use of extension headers in subsequent packets sent to the use of extension headers in subsequent packets sent to the
destination in order to avoid further occurrences of packets being destination in order to avoid further occurrences of packets being
discarded. discarded.
1.2 Aggregate header limits 1.2 Aggregate header limits
Many hardware devices implement a parsing buffer of a fixed size to Many 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. Parsing buffers have been implemented with device needs to examine. If the aggregate length of headers in a
various sizes (512 bytes is common, although some devices have packet exceeds the size of the parsing buffer, a device will either
smaller sizes). If the aggregate length of headers in a packet discard the packet or defer processing to a software slow path. In
exceeds the size of the parsing buffer, a device will either discard any case, no indication of a problem is sent back to the sender.
the packet or defer processing to a software slow path. In 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. A source host that receives an ICMPv6 error can processing limit. A source host that receives an ICMPv6 error can
modify the headers used in subsequent packets to try to avoid further modify the headers used in subsequent packets to try to avoid further
occurrences of packets being discarded or relegated to a slow path. occurrences of packets being discarded or relegated to a slow path.
2 ICMPv6 errors for extension header limits 2 ICMPv6 errors for extension header limits
Four new codes are defined for Parameter Problem types and Four new codes are defined for the Parameter Problem type and
applicability of one existing code is extended for ICMPv6 errors for applicability of one existing code is extended for ICMPv6 errors for
extension header limits. extension header limits.
2.1 Format 2.1 Format
The format of the ICMPv6 message for an extension header limit The format of the ICMPv6 message for an extension header limit
exceeded error is: 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
skipping to change at page 5, line 40 skipping to change at page 6, line 40
[RFC8200] specifies that a destination host should send an [RFC8200] specifies that a destination host should send an
"unrecognized next header type" when a Next Header value is "unrecognized next header type" when a Next Header value is
unrecognized in a packet. This document extends this to allow unrecognized in a packet. This document extends this to allow
intermediate nodes to send this same error for a packet that is intermediate nodes to send this same error for a packet that is
discarded because the node does not recognize a Next Header type. discarded because the node does not recognize a Next Header type.
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 the its examination. The ICMPv6 Pointer field is set to the offset of the
unrecognized value within the original packet. unrecognized next header value within the original packet.
Note that when the original sender receives the ICMPv6 error it can Note that when the original sender receives the ICMPv6 error it can
differentiate between the message being sent by a destination host, differentiate between the message being sent by a destination host,
per [RFC4443], and an error sent by an intermediate host based on per [RFC4443], and an error sent by an intermediate host based on
matching the source address of the ICMPv6 packet and the destination matching the source address of the ICMPv6 packet and the destination
address of the packet in the ICMPv6 data. address of the packet in the ICMPv6 data.
2.3 Extension header too big (code 4) 2.3 Extension header too big (code 4)
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 5) 2.4 Extension header chain too long (code 5)
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 because an extension header chain exceeds its processing header chain that exceeds its processing limits.
limit.
There are two different limits that might be applied: a limit on the There are two different limits that might be applied: a limit on the
total size in octets of the header chain, and a limit on the number total size in octets of the header chain, and a limit on the number
of extension headers in the chain. This error code is used in both of extension headers in the chain. This error code is used in both
cases. In the case that the size limit is exceeded, the ICMPv6 cases. In the case that the size limit is exceeded, the ICMPv6
Pointer is set to first octet beyond the limit. In the case that the Pointer is set to first octet beyond the limit. In the case that the
number of extension headers is exceeded, the ICMPv6 Pointer is set to number of extension headers is exceeded, the ICMPv6 Pointer is set to
the offset of first octet of the first extension header that is the offset of first octet of the first extension header that is
beyond the limit. beyond the limit.
skipping to change at page 6, line 43 skipping to change at page 7, line 42
2.6 Option too big (code 7) 2.6 Option too big (code 7)
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 option exceeds two different cases: when the length of an individual option exceeds
a limit, or when the length or number of consecutive padding options a limit, or when the length or number of consecutive padding options
exceeds a limit. exceeds a limit.
If a packet is discarded because the length of a Hop-by-Hop or If a packet is discarded because the length of a Hop-by-Hop or
Destination option exceeds a processing limit, a node SHOULD send an Destination option exceeds a processing limit, a node SHOULD send an
ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 Pointer ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 Pointer
field is set to the offset of the first octet in the option that field is set to the offset of the first octet of the option that
exceeds the limit. exceeds the limit.
If a packet is discarded because the length or number of consecutive If a packet is discarded because the length or number of consecutive
padding options (PAD1 and PADN) exceeds a limit, a node SHOULD send padding options (PAD1 and PADN) exceeds a limit, a node SHOULD send
and an ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 and an ICMPv6 Parameter Problem with code equal to 7. The ICMPv6
Pointer field is set to the offset of first octet of the padding Pointer field is set to the offset of 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:
skipping to change at page 7, line 26 skipping to change at page 8, line 26
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 Destination Unreachable type for aggregate
header limits. header limits.
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 extended structure message format as defined in [RFC4884]. The extended structure
contains a pointer to the octet beyond the limit. contains a pointer to the first octet beyond the limit.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Length | unused | | unused | Length | unused |
skipping to change at page 9, line 17 skipping to change at page 10, line 17
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" for number of extension 7) "Extension header chain too long" for number of extension
headers exceeding a limit headers exceeding a limit
8) "Extension header chain too long" for size of the extension 8) "Extension header chain too long" for size of an extension
header chain exceeding a limit header chain exceeding a limit
9) "Headers too long" 9) "Headers too long"
4.2 Host response 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
an appropriate action. an appropriate action.
The general validations for ICMP as described in [RFC4443] are
applicable. The packet in the ICMP data SHOULD be validated to match
the upper layer process or connection that 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 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 mis-configured 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 application * An error SHOULD be reported to an application if the application
enabled extension headers for its traffic. In response, The enabled extension headers for its traffic. In response, the
application MAY terminate communications if extension headers application may terminate communications if extension headers
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 modify its destination indicated by the ICMPv6 error, or attempt modify its
use of extension headers or headers to avoid further packet use of extension headers or headers to avoid further packet
discards. discards.
* A host system SHOULD take appropriate action if it is * A host system SHOULD take appropriate action if it is
automatically inserting extension headers into packets on behalf automatically inserting extension headers into packets on behalf
of the application. If the offending extension header is not of the application. If the offending extension header is not
required for communication, the host MAY either stop sending it required for communication, the host may either stop sending it
or otherwise modify its use in subsequent packets sent to the or otherwise modify its use in subsequent packets sent to the
destination indicated in the ICMPv6 error. destination indicated in the ICMPv6 error.
5 Security Considerations 5 Applicability and use cases
5.1 Nonconformant packet discard
The ICMP errors defined in this specification may be applicable to
scenarios for which a node is dropping packets outside the auspices
of any standard specification. For instance, an intermediate node
might send a "Headers too long" code in the case that it drops a
packet because it is unable to parse deep enough to extract transport
layer information needed for packet filtering. Such behavior might be
considered nonconformant (with respect to [RFC8200] for instance).
This specification does not advocate behaviors that might be
considered nonconformant. However, packet discard does occur in real
deployments and the intent of this specification is provide
visibility as to why packets are being discarded. In the spirit that
providing some reason is better than silent drop, this specification
RECOMMENDS the sending of ICMP errors even in cases where a node
might be discarding packets per a nonconformant behavior.
5.2 Reliability of ICMP
ICMP is fundamentally an unreliable protocol and in real deployment
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
best effort to be delivered. No protocol should be implemented that
relies on reliable delivery of ICMP messages. If necessary,
alternative or additional mechanisms may used to augment the
processes used to to deduce the reason that packets are being
discarded. Such alternative mechanisms are out of scope of this
specification.
5.3 Processing limits
This sections discusses the trends and motivations of processing
limits that warrant ICMP errors.
5.3.1 Long headers and header chains
Historically, packet headers have been relatively simple and
straightforward. For instance, the majority of packets in the
Internet are plain TCP or UDP carried in IPv4 or IPv6. The trend
towards more complex headers, and hence the need to process longer
headers, is driven by:
* Increasing prevalence of deep packet inspection in middleboxes.
In particular, many intermediate nodes now parse into network
layer encapsulation protocols.
* Deployment of routing headers. For instance, [SRH] defines an
extension header format that includes a list of IPv6 addresses
which may consume a considerable number of bytes.
* Development of In-situ OAM headers that allow a rich set of
measurements to be gathered in the data path at the cost of
additional header overhead which may be significant [IOAM].
* Other emerging use cases of Hop-by-Hop options.
5.3.2 At end nodes
End node hosts may implement limits on processing extension headers
as described in [RFC8504]. Host implementations are usually software
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.
5.3.3 At intermediate nodes
Hardware devices that process packet headers may have limits as to
how many headers or bytes of headers they can process. For instance,
a middlebox hardware implementation might have a parsing buffer that
contains some number of bytes of packet headers to process. Parsing
buffers typically have a fixed size such as sixty-four, 128, or 256
bytes. In addition, hardware implementations (and some software
implementations) often don't have loop constructs. So for instance,
processing of a TLV list might be implemented as an unrolled loop so
that the number of TLVs that can be processed is limited. For
instance, an implementation might unroll a TLV parsing loop to
process at most eight TLVs.
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 for denial of service attack or as a means to covertly be exploited for denial of service attack or as a means to covertly
deduce processing capabilities of nodes as a precursor to denial of deduce processing capabilities of nodes as a precursor to denial of
service attack. As such, an implementation SHOULD allow configurable service attack. As such, an implementation SHOULD allow configurable
policy to withhold sending of the ICMP errors described in this policy to withhold sending of the ICMP errors described in this
specification in environments where security of ICMP errors is a specification in environments where security of ICMP errors is a
concern. concern.
6 IANA Considerations 7 IANA Considerations
6.1 Parameter Problem codes 7.1 Parameter Problem codes
IANA is requested to assign the following codes for ICMPv6 type 4 IANA is requested to assign the following codes for ICMPv6 type 4
"Parameter Problem": "Parameter Problem":
4 - Extension header too big 4 - Extension header too big
5 - Extension header chain too long 5 - Extension header chain too long
6 - Too many options in extension header 6 - Too many options in extension header
7 - Option too big 7 - Option too big
6.2 Destination Unreachable codes 7.2 Destination Unreachable codes
IANA is requested to assign the following codes for ICMPv6 type 1 IANA is requested to assign the following codes for ICMPv6 type 1
"Destination Unreachable": "Destination Unreachable":
8 - Headers too long 8 - Headers too long
7 Acknowledgments 8 Acknowledgments
The author would like to thank Ron Bonica, Bob Hinden, and Nick The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard,
Hilliard for their comments and suggestions that improved this Michael Richardson, Mark Smith, and Suresh Krishnan for their
document. comments and suggestions that improved this document.
8 References 9 References
8.1 Normative References 9.1 Normative References
[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 Protocol Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, DOI Version 6 (IPv6) Specification", RFC 4443, DOI
10.17487/RFC4443, March 2006, <http://www.rfc- 10.17487/RFC4443, March 2006, <http://www.rfc-
editor.org/info/rfc4443>. editor.org/info/rfc4443>.
[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, DOI (IPv6) Specification", STD 86, RFC 8200, DOI
10.17487/RFC8200, July 2017, <https://www.rfc- 10.17487/RFC8200, July 2017, <https://www.rfc-
skipping to change at page 12, line 10 skipping to change at page 15, line 10
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of
IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045,
December 2013, <http://www.rfc-editor.org/info/rfc7045>. December 2013, <http://www.rfc-editor.org/info/rfc7045>.
[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, <https://www.rfc-
editor.org/info/rfc4884>. editor.org/info/rfc4884>.
8.2 Informative References 9.2 Informative References
[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>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, DOI ICMPv6 Messages in Firewalls", RFC 4890, DOI
10.17487/RFC4890, May 2007, <https://www.rfc- 10.17487/RFC4890, May 2007, <https://www.rfc-
editor.org/info/rfc4890>. editor.org/info/rfc4890>.
[SRH] Filsfils, C., Ed.. Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., Voyer, D., "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-21 (work in
progress), August 2019. February
[IOAM] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
Lpaukhov, P., Spiegel, M., Krishnan, S., Asati, R., "In-
situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-ipv6-
options-02, March 2018
Author's Address Author's Address
Tom Herbert Tom Herbert
Quantonium Intel
Santa Clara, CA Santa Clara, CA
USA USA
Email: tom@quantonium.net Email: tom@quantonium.net
 End of changes. 31 change blocks. 
71 lines changed or deleted 173 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/