draft-ietf-6man-icmp-limits-00.txt   draft-ietf-6man-icmp-limits-01.txt 
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Standard Quantonium Intended Status: Standard Quantonium
Expires: November 2018 Expires: November 2019
May 29, 2018 May 1, 2019
ICMPv6 errors for discarding packets due to processing limits ICMPv6 errors for discarding packets due to processing limits
draft-ietf-6man-icmp-limits-00 draft-ietf-6man-icmp-limits-01
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 document 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
skipping to change at page 1, line 47 skipping to change at page 1, line 47
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 6 3 ICMPv6 error for aggregate header limits . . . . . . . . . . . 6
3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 8 4.1 Priority of reporting . . . . . . . . . . . . . . . . . . . 8
4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Host response . . . . . . . . . . . . . . . . . . . . . . . 8
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 10 6.1 Parameter Problem codes . . . . . . . . . . . . . . . . . . 10
6.2 Destination Unreachable codes . . . . . . . . . . . . . . . 10 6.2 Destination Unreachable codes . . . . . . . . . . . . . . . 10
8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
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]. ICMPv6 code points are defined as an update to [RFC4443]. Four of the
errors are specific to processing limits of extension headers;
Four of the errors are specific to processing limits of extension another error is used when the aggregate protocol headers in a packet
headers; another error is used when the aggregate protocol headers in exceed the processing limits of a node.
a packet exceed the processing limits of a node.
1.1 Extension header limits 1.1 Extension header limits
With 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 and must fit into one extension headers may have a length of 2048 octets and must fit into
MTU. Destination Options and Hop by Hop Options contain a list 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, and the minimum size of an option length of the data field in octets, and the minimum size of an option
(non-pad type) is two bytes and the maximum length is 257 bytes. The (non-pad type) is two bytes and the maximum length is 257 bytes. 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 also be skipped
over by a receiver if they are unknown and the Option Type indicates over by a receiver if they are unknown and the Option Type indicates
to skip (first two bits are 00). to 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 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 extensions headers and Destination hosts are expected to process all extensions headers and
options in Hop-by-Hop and Destination Options. options in Hop-by-Hop and Destination Options.
Due to the variable lengths, high limits of lengths of extension Due to the variable lengths, high maximum lengths, or potential for
headers, or potential for Denial of Service attack; many devices Denial of Service attack of extension headers-- many devices impose
impose operational limits of extension headers in packets they can operational limits on extension headers in packets they process.
process. [RFC7045] discusses the requirements of intermediate nodes [RFC7045] discusses the requirements of intermediate nodes that
that discard packets because of unrecognized extension headers. When discard packets because of unrecognized extension headers. [RFC8504]
a limit is exceeded, the typical behavior is to silently discard a discusses limits that may be applied on the number of options in Hop-
packet. The limits are non-standard and may be configurable per by-Hop or Destination Options extension headers. When a limit is
implementation. Both intermediate nodes and end hosts may institute exceeded, the typical behavior is to silently discard a packet. Both
such limits on extension header processing. intermediate nodes and end hosts may institute limits on extension
header processing.
This document defines three Parameter Problem codes and extends the This document defines three Parameter Problem codes and extends the
applicably of an existing code that are sent by a node that discards applicably of an existing code that may be sent by a node that
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 the exceeded. A source host that receives an ICMPv6 error can modify its
use of extension headers in subsequent packets to the destination in use of extension headers in subsequent packets sent to the
order to avoid further occurrences of packets being discarded. destination in order to avoid further occurrences of packets being
discarded.
1.2 Aggregate header limits 1.2 Aggregate header limits
Many hardware devices implement a parsing buffer of a fixed sized to Many hardware devices implement a parsing buffer of a fixed sized 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. Parsing buffers have been implemented with
various sizes (512 bytes is common, some devices have smaller sizes). various sizes (512 bytes is common, although some devices have
smaller sizes). If the aggregate length of headers in a packet
When the aggregate length of headers in a packet exceeds the size of exceeds the size of the parsing buffer, a device will either discard
the parsing buffer, a device will typically either discard the packet the packet or defer processing to a software slow path. In any case,
or defer processing to a software slow path. In either case, no no indication of a problem is sent back to the sender.
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 (e.g. exceeding the size of a parsing buffer). A processing limit. A source host that receives an ICMPv6 error can
source host that receives an ICMPv6 error can modify the headers used modify the headers used in subsequent packets to try to avoid further
in subsequent packets to try to avoid further occurrences of packets occurrences of packets being discarded or relegated to a slow path.
being discarded or relegated to a slow path.
2 ICMPv6 errors for extension header limits 2 ICMPv6 errors for extension header limits
Three new codes are defined for Parameter Problem type and Three new codes are defined for 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
skipping to change at page 5, line 36 skipping to change at page 5, line 34
The pointer will point beyond the end of the ICMPv6 packet if The pointer will point beyond the end of the ICMPv6 packet if
the field having a problem is beyond what can fit in the the field having a problem is beyond what can fit in the
maximum size of an ICMPv6 error message. maximum size of an ICMPv6 error message.
2.2 Unrecognized Next Header type encountered (code 1) 2.2 Unrecognized Next Header type encountered (code 1)
[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 a 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 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
skipping to change at page 6, line 13 skipping to change at page 6, line 11
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 chains exceeds it processing header chain because an extension header chain exceeds it processing
limit. 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 a 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.
2.5 Too many options in extension header (code 6) 2.5 Too many options in extension header (code 6)
An ICMPv6 Parameter Problem with code for "too many options in An ICMPv6 Parameter Problem with code for "too many options in
extension header" SHOULD be sent when a node discards a packet with extension header" SHOULD be sent when a node discards a packet with
an extension header that has a number of options that exceed the an extension header that has a number of options that exceed the
processing limits of the node. This code is applicable for processing limits of the node. This code is applicable for
Destination options or 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.
3 ICMPv6 error for aggregate header limits 3 ICMPv6 error for aggregate header limits
One code is defined for Destination Unreach type for aggregate header One code is defined for Destination Unreachable type for aggregate
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 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:
skipping to change at page 8, line 15 skipping to change at page 8, line 15
4 Operation 4 Operation
Nodes that send or receive ICMPv6 errors due to header processing Nodes that send or receive ICMPv6 errors due to header processing
limits MUST generally comply with ICMPv6 processing as specified in limits MUST generally comply with ICMPv6 processing as specified in
[RFC4443]. [RFC4443].
4.1 Priority of reporting 4.1 Priority of reporting
More than one ICMPv6 error may be applicable to report for a packet. More than one ICMPv6 error may be applicable to report for a packet.
For instance, the number of extension headers in a packet might For instance, the number of extension headers in a packet might
exceed a limit, and the aggregate length of protocol headers might exceed a limit and the aggregate length of protocol headers might
also exceed a limit. Only one ICMPv6 error should be sent for a also exceed a limit. Only one ICMPv6 error SHOULD be sent for a
packet, so a priority is defined to determine which error to report. packet, so a priority is defined to determine which error to report.
The reporting priority of ICMPv6 errors for processing limits is from The RECOMMENDED reporting priority of ICMPv6 errors for processing
highest to lowest priority: limits is from highest to lowest priority:
1) Real error (existing codes) 1) Real error (existing codes)
2) Unrecognized Next Header type encountered by an intermediate 2) Unrecognized Next Header type encountered by an intermediate
node node
3) Too many options in an extension header 3) Too many options in an extension header
4) Extension header too big 4) Extension header too big
5) Extension header chain too long for number of extension headers 5) Extension header chain too long for number of extension headers
limit exceeded exceeding a limit
6) Extension header chain too long for size of the extension 6) Extension header chain too long for size of the extension
header chain exceeding a limit header chain exceeding a limit
7) Headers too long 7) 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 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 would be useful for instance to debug when a node is retained. This, for instance, would be useful for debugging when a
mis-configured and unexpectedly discarding packets, or when a new node is mis-configured and unexpectedly discarding packets, or when a
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 cause 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. The application MAY enabled extension headers for its traffic. In response, The
either terminate a connection if extension headers are required, application MAY terminate communications if extension headers
stop using extension headers in packets to the destination are required, stop using extension headers in packets to the
indicated in packet of 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 the packet drop. use of extension headers or headers to avoid further packet
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 automatically inserting extension headers into packets
unbeknownst to the application. If the offending extension unbeknownst to the application. If the offending extension
header is not required for communication, the host MAY either header is not required for communication, the host MAY either
stop sending it or otherwise modify its use in subsequent stop sending it or otherwise modify its use in subsequent
packets sent to the destination indicated in the ICMPv6 error. packets sent to the destination indicated in the ICMPv6 error.
5 Security Considerations 5 Security Considerations
skipping to change at page 10, line 25 skipping to change at page 10, line 25
6 - Too many options in extension header 6 - Too many options in extension header
6.2 Destination Unreachable codes 6.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
8 Acknowledgments 7 Acknowledgments
The authors would like to thank Ron Bonica, Bob Hinden for their The author would like to thank Ron Bonica, Bob Hinden for their
comments and suggestions that improved this document. comments and suggestions that improved this document.
7 References
7.1 Normative References 8 References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 8.1 Normative References
(IPv6) Specification", STD 86, RFC 8200, DOI
10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rfc8200>.
[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
(IPv6) Specification", STD 86, RFC 8200, DOI
10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rfc8200>.
[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>.
7.2 Informative References 8.2 Informative References
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019,
<https://www.rfc-editor.org/info/rfc8504>.
Author's Address Author's Address
Tom Herbert Tom Herbert
Quantonium Quantonium
Santa Clara, CA Santa Clara, CA
USA USA
Email: tom@qantonium.net Email: tom@quantonium.net
 End of changes. 33 change blocks. 
73 lines changed or deleted 78 lines changed or added

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