ICMPv6 errors for discarding packets due to processing limits
draft-ietf-6man-icmp-limits-08

Versions: (draft-herbert-6man-icmp-limits) 00 01         Standards Track
          02 03 04 05 06 07 08                                          
Network Working Group                                         T. Herbert
Internet-Draft                                                     Intel
Intended status: Standards Track                          March 18, 2020
Expires: September 19, 2020


     ICMPv6 errors for discarding packets due to processing limits
                     draft-ietf-6man-icmp-limits-08

Abstract

   Network nodes may discard packets if they are unable to process
   protocol headers of packets due to processing constraints or limits.
   When such packets are dropped, the sender receives no indication so
   it cannot take action to address the cause of discarded packets.
   This specification defines several new ICMPv6 errors that can be sent
   by a node that discards packets because it is unable to process the
   protocol headers.  A node that receives such an ICMPv6 error may use
   the information to diagnose packet loss and may modify what it sends
   in future packets to avoid subsequent packet discards.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 19, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Herbert                Expires September 19, 2020               [Page 1]


Internet-Draft                ICMPv6 limits                   March 2020


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Extension header limits . . . . . . . . . . . . . . . . .   3
     1.2.  Aggregate header limits . . . . . . . . . . . . . . . . .   4
     1.3.  Nonconformant packet discard  . . . . . . . . . . . . . .   4
     1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  ICMPv6 errors for extension header limits . . . . . . . . . .   5
     2.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Unrecognized Next Header type encountered by intermediate
           node (code TBA1)  . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Extension header too big (code TBA2)  . . . . . . . . . .   6
     2.4.  Extension header chain too long (code TBA3) . . . . . . .   6
     2.5.  Too many extension headers (code TBA4)  . . . . . . . . .   6
     2.6.  Too many options in extension header (code TBA5)  . . . .   7
     2.7.  Option too big (code TBA6)  . . . . . . . . . . . . . . .   7
   3.  ICMPv6 error for aggregate header limits  . . . . . . . . . .   7
     3.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Priority of reporting . . . . . . . . . . . . . . . . . .  10
     4.2.  Host response . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Applicability and use cases . . . . . . . . . . . . . . . . .  11
     5.1.  Reliability of ICMP . . . . . . . . . . . . . . . . . . .  12
     5.2.  Processing limits . . . . . . . . . . . . . . . . . . . .  12
       5.2.1.  Long headers and header chains  . . . . . . . . . . .  12
       5.2.2.  At end hosts  . . . . . . . . . . . . . . . . . . . .  12
       5.2.3.  At intermediate nodes . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Parameter Problem codes . . . . . . . . . . . . . . . . .  13
     7.2.  Destination Unreachable codes . . . . . . . . . . . . . .  14
     7.3.  ICMP Extension Object Classes and Class Sub-types . . . .  14
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16








Herbert                Expires September 19, 2020               [Page 2]


Internet-Draft                ICMPv6 limits                   March 2020


1.  Introduction

   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
   necessary protocol headers because of processing constraints or
   limits.  New ICMPv6 code points are defined to supplement those
   defined in [RFC4443].  Six of the errors are specific to processing
   of extension headers; another error is used when the aggregate
   protocol headers in a packet exceed the processing limits of a node.

1.1.  Extension header limits

   In IPv6, optional internet-layer information is carried in one or
   more IPv6 Extension Headers [RFC8200].  Extension Headers are placed
   between the IPv6 header and the Upper-Layer Header in a packet.  The
   term "Header Chain" refers collectively to the IPv6 header, Extension
   Headers, and Upper-Layer Headers occurring in a packet.  Individual
   extension headers may have a maximum length of 2048 octets and must
   fit into a single packet.  Destination Options and Hop-by-Hop Options
   contain a list of options in Type-length-value (TLV) format.  Each
   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
   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
   the source to the destination.  Options may be skipped over by a
   receiver if they are unknown and the Option Type indicates to skip
   (first two high order bits are 00).

   Per [RFC8200], except for Hop by Hop options, extension headers are
   not examined or processed by intermediate nodes.  Many intermediate
   nodes, however, do examine extension headers for various purposes.
   For instance, a node may examine all extension headers to locate the
   transport header of a packet in order to implement transport layer
   filtering or to track connections to implement a stateful firewall.

   Destination hosts are expected to process all extension headers and
   options in Hop-by-Hop and Destination Options.

   Due to the variable lengths, high maximum lengths, or potential for
   Denial of Service attack of extension headers, many devices impose
   operational limits on extension headers in packets they process.
   [RFC7045] discusses the requirements of intermediate nodes that
   discard packets because of unrecognized extension headers.  [RFC8504]
   discusses limits that may be applied to the number of options in Hop-
   by-Hop Options or Destination Options extension headers.  Both
   intermediate nodes and end hosts may apply limits to extension header
   processing.  When a limit is exceeded, the typical behavior is to
   silently discard the packet.



Herbert                Expires September 19, 2020               [Page 3]


Internet-Draft                ICMPv6 limits                   March 2020


   This specification defines six Parameter Problem codes that may be
   sent by a node that discards a packet due to processing limits of
   extension headers being exceeded.  The information in these ICMPv6
   errors may be used for diagnostics to determine why packets are being
   dropped.  Additionally, a source node that receives these ICMPv6
   errors may be able to modify its use of extension headers in
   subsequent packets sent to the destination in order to avoid further
   occurrences of packets being discarded.

1.2.  Aggregate header limits

   Some hardware devices implement a parsing buffer of a fixed size to
   process packets.  The parsing buffer is expected to contain all the
   headers (often up to a transport layer header for filtering) that 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
   discard the packet or will 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
   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
   processing limit.  The information in this ICMPv6 error may be used
   for diagnostics to determine why packets are being dropped.
   Additionally, a source node that receives this ICMPv6 error may be
   able to modify the headers used in subsequent packets to try to avoid
   further occurrences of packets being discarded.

1.3.  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, the sending of ICMP
   errors is RECOMMENDED even in cases where a node might be discarding
   packets per a nonconformant behavior.






Herbert                Expires September 19, 2020               [Page 4]


Internet-Draft                ICMPv6 limits                   March 2020


1.4.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  ICMPv6 errors for extension header limits

   Six new codes are defined for the Parameter Problem type.

2.1.  Format

   The format of the ICMPv6 Parameter Problem message [RFC4443] for an
   extension header limit exceeded error is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Pointer                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    As much of invoking packet                 |
   +               as possible without the ICMPv6 packet           +
   |              exceeding the minimum IPv6 MTU [RFC8200]         |

   IPv6 Header Fields:

      Destination Address
         Copied from the Source Address field of the invoking packet.

   ICMPv6 Fields:

      Type
         4 (Parameter Problem type)

      Code (pertinent to this specification)

         TBA1 -  Unrecognized Next Header type encountered by
                 intermediate node
         TBA2 -  Extension header too big
         TBA3 -  Extension header chain too long
         TBA4 -  Too many extension headers
         TBA5 -  Too many options in extension header
         TBA6 -  Option too big

      Pointer




Herbert                Expires September 19, 2020               [Page 5]


Internet-Draft                ICMPv6 limits                   March 2020


         Identifies the octet offset within the invoking packet where
         the problem occurred.

         The pointer will point beyond the end of the Invoking Packet if
         the field exceeding the limit is beyond what can fit in the
         maximum size of an ICMPv6 error message extension.  If the
         pointer is used as an offset to read the data in the invoking
         packet then a node MUST first validate that the pointer value
         is less than the length of the Invoking Packet data.

2.2.  Unrecognized Next Header type encountered by intermediate node
      (code TBA1)

   This code SHOULD be sent by an intermediate node that discards a
   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 unrecognized next header value within the original packet.

   Note that this code is sent by intermediate nodes, and SHOULD NOT be
   sent by a final destination.  If a final destination node observes an
   unrecognized header then it SHOULD send an ICMP Parameter Problem
   message with an ICMP Code value of 1 ("unrecognized Next Header type
   encountered") as specified in [RFC8200].

2.3.  Extension header too big (code TBA2)

   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
   extension header exceeds its processing limit.  The ICMPv6 Pointer
   field is set to the offset of the first octet in the extension header
   that exceeds the limit.

2.4.  Extension header chain too long (code TBA3)

   An ICMPv6 Parameter Problem with code for "extension header chain too
   long" SHOULD be sent when a node discards a packet with an extension
   header chain that exceeds a limit on the total size in octets of the
   header chain.  The ICMPv6 Pointer is set to first octet beyond the
   limit.

2.5.  Too many extension headers (code TBA4)

   An ICMPv6 Parameter Problem with code for "too many extension
   headers" SHOULD be sent when a node discards a packet with an
   extension 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 the first extension header that is beyond
   the limit.


Herbert                Expires September 19, 2020               [Page 6]


Internet-Draft                ICMPv6 limits                   March 2020


2.6.  Too many options in extension header (code TBA5)

   An ICMPv6 Parameter Problem with code for "too many options in
   extension header" SHOULD be sent when a node discards a packet with
   an extension header that has a number of options that exceed the
   processing limits of the node.  This code is applicable for
   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.

2.7.  Option too big (code TBA6)

   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
   Destination option exceeds a limit, or when the length or number of
   consecutive Hop-by-Hop or Destination padding options exceeds a
   limit.  In the case that the length of an option exceeds a processing
   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
   length or number of padding options exceeds a limit, the ICMPv6
   Pointer field is set to the offset of first octet of the padding
   option that exceeds the limit.

   Possible limits related to padding include:

      *  The number of consecutive PAD1 options in destination options
         or hop-by-hop options is limited to seven octets [RFC8504].

      *  The length of a PADN options in destination options or hop-by-
         hop options is limited seven octets [RFC8504].

      *  The aggregate length of a set of consecutive PAD1 or PADN
         options in destination options or hop-by-hop options is limited
         to seven octets.

3.  ICMPv6 error for aggregate header limits

   One code is defined for Destination Unreachable type for aggregate
   header limits.

   This ICMP error may be applied to other headers in a packet than just
   the IPv6 header or IPv6 extension headers.  Therefore, a Destination
   Unreachable type with a multi-part ICMPv6 message format is used in
   lieu of the Parameter Problem type which only indicates errors
   concerning IPv6 headers.







Herbert                Expires September 19, 2020               [Page 7]


Internet-Draft                ICMPv6 limits                   March 2020


3.1.  Format

   The error for aggregate header limits employs a multi-part ICMPv6
   message format as defined in [RFC4884].  The extension object class
   "Extended Information" is defined to contain objects for ancillary
   information pertaining to an ICMP Destination Unreachable error.
   Within this object class, the sub-type "Pointer" is defined which
   contains the Pointer field with similar semantics to the Pointer
   field in ICMP Parameter Problem errors.

   The format of the ICMPv6 message for an aggregate header limit
   exceeded is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
   |     Type      |     Code      |          Checksum             | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
   |    Length     |                  Unused                       | C
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
   |                           Invoking Packet                     | P
   ~      As much of invoking packet as possible without the       ~ |
   |    ICMPv6 packet exceeding the minimum IPv6 MTU [RFC8200]     |/
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
   |Version|       Reserved        |           Checksum            |\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E
   |             Length            |   Class-Num   |   C-Type      | X
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T
   |                            Pointer                            | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

   IPv6 Header Fields:

      Destination Address
         Copied from the Source Address field of the invoking packet.

   ICMPv6 Fields:

      Type
         1 - Destination Unreachable type

      Code (pertinent to this specification)
         TBA7 - Headers too long

      Length
         Length of the padded Invoking Packet measured in 64-bit words.
         The ICMP extension structure immediately follows the padded
         Invoking Packet



Herbert                Expires September 19, 2020               [Page 8]


Internet-Draft                ICMPv6 limits                   March 2020


      Invoking Packet
         Contains as much of invoking packet as possible without the
         ICMPv6 packet exceeding the minimum IPv6 MTU.  The Invoking
         Packet MUST be zero padded to the nearest 64-bit boundary
         [RFC4884].  If the original invoking packet did not contain 128
         octets, the Invoking Packet MUST be zero padded to 128 octets.

   ICMP Extension Fields:

      Version
         2 - per [RFC4884]

      Reserved
         0

      Checksum
         The one's complement checksum of the ICMP extension [RFC4884]

      Length
         8 - length of the object header and Pointer field

      Class-Num
         TBA8 - Extended Information class

      C-Type
         TBA9 - Pointer sub-type

      Pointer
         Identifies the octet offset within the invoking packet where a
         limit was exceeded.

         The pointer will point beyond the end of the Invoking Packet if
         the field exceeding the limit is beyond what can fit in the
         maximum size of an ICMPv6 error message with the ICMP
         extension.  If the pointer is used as an offset to read the
         data in the invoking packet then a node MUST first validate
         that the pointer value is less than the length of the Invoking
         Packet data.

3.2.  Usage

   An ICMPv6 Destination Unreachable error with code for "headers too
   long" SHOULD be sent when a node discards a packet because the
   aggregate length of headers in the packet exceeds the processing
   limits of the node.  The Pointer in the extended ICMPv6 structure is
   set to the offset of the first octet that exceeds the limit.





Herbert                Expires September 19, 2020               [Page 9]


Internet-Draft                ICMPv6 limits                   March 2020


   This error is sent in response to a node dropping a packet because
   the aggregate header chain exceeds the processing limits of a node.
   The aggregate header chain may be composed of protocol headers other
   than an IPv6 header and IPv6 extension headers.  For instance, in the
   case of a node parsing a UDP encapsulation protocol, the
   encapsulating UDP header would be considered to be in the aggregate
   header chain.

   As noted in section 4.1, the ICMPv6 Destination Unreachable error
   with code for "headers too long" has the lowest precedence of the
   ICMP errors discussed in this specification.  If a packet contains an
   error corresponding to a Parameter Problem code then a node SHOULD
   send the Parameter Problem error instead of sending the ICMPv6
   Destination Unreachable error with code for "headers too long".

4.  Operation

   Nodes that send or receive ICMPv6 errors due to header processing
   limits MUST comply with ICMPv6 processing as specified in [RFC4443].

4.1.  Priority of reporting

   More than one ICMPv6 error may be applicable to report for a packet.
   For instance, the number of extension headers in a packet 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
   packet, so a priority is defined to determine which error to report.

   The RECOMMENDED reporting priority of ICMPv6 errors for processing
   limits is from highest to lowest priority:

      1) Existing ICMP errors defined in [RFC4443]

      2) "Unrecognized Next Header type encountered by intermediate
         node"

      3) "Extension header too big"

      4) "Option too big" for length or number of consecutive padding
         options exceeding a limit

      5) "Option too big" for the length of an option exceeding a limit

      6) "Too many options in an extension header"

      7) "Extension header chain too long" headers exceeding a limit

      8) "Too many extension headers"



Herbert                Expires September 19, 2020              [Page 10]


Internet-Draft                ICMPv6 limits                   March 2020


      9) "Headers too long"

4.2.  Host response

   When a source host receives an ICMPv6 error for a processing limit
   being exceeded, it SHOULD verify the ICMPv6 error is valid and take
   appropriate action as suggested below.

   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
   debugging packet loss.  The details of the error, including the
   addresses and the offending extension header or data, should be
   retained.  This, for instance, would be useful for debugging when a
   node is mis-configured and unexpectedly discarding packets, or when a
   new extension header is being deployed.

   A host MAY modify its usage of protocol headers in subsequent packets
   to avoid repeated occurrences of the same error.

   For ICMPv6 errors caused by extension header limits being exceeded:

      *  An error SHOULD be reported to an application if the
         application enabled extension headers for its traffic.  In
         response, the application may terminate communications if
         extension headers are required, stop using extension headers in
         packets to the destination indicated by the ICMPv6 error, or
         attempt to modify its use of extension headers or headers to
         avoid further packet discards.

      *  A host system SHOULD take appropriate action if it is creating
         packets with extension headers on behalf of the application.
         If the offending extension header is not required for
         communication, the host may either stop sending it or otherwise
         modify its use in subsequent packets sent to the destination
         indicated in the ICMPv6 error.

5.  Applicability and use cases








Herbert                Expires September 19, 2020              [Page 11]


Internet-Draft                ICMPv6 limits                   March 2020


5.1.  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 deduce the reason that packets are being discarded.
   For instance, the messages may be correlated with information
   attained through Packetization Layer Path MTU Discovery (PLMTUD)
   [RFC4821] or Happy Eyeballs for IPv6 [RFC8305].  Details of the
   interaction with alternative mechanisms are out of scope of this
   specification.

5.2.  Processing limits

   This section discusses the trends and motivations of processing
   limits that warrant ICMP errors.

5.2.1.  Long headers and header chains

   The trend towards longer and more complex headers and header chains
   needing to be processed by end nodes, as well as intermediate nodes,
   is driven by:

      *  Increasing prevalence of deep packet inspection in middleboxes.
         In particular, many intermediate nodes now parse network layer
         encapsulation protocols or transport layer protocols.

      *  Deployment of routing headers.  For instance,
         [I-D.ietf-6man-segment-routing-header] 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
         [I-D.ioametal-ippm-6man-ioam-ipv6-options].

      *  Other emerging use cases of Hop-by-Hop and Destination options.

5.2.2.  At end hosts

   End 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.




Herbert                Expires September 19, 2020              [Page 12]


Internet-Draft                ICMPv6 limits                   March 2020


   Limits imposed by a software stack are more likely to be for denial
   of service mitigation or performance.

5.2.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.  Processing of a
   TLV list might be implemented as an unrolled loop so that the number
   of TLVs that can be processed is limited.

6.  Security Considerations

   The security considerations for ICMPv6 described in [RFC4443] are
   applicable.  The ICMP errors described in this document MAY be
   filtered by firewalls in accordance with [RFC4890].

   In some circumstances, the sending of ICMP errors might conceptually
   be exploited a means to covertly deduce processing capabilities of
   nodes.  As such, an implementation SHOULD allow configurable policy
   to withhold sending of the ICMP errors described in this
   specification in environments where security of ICMP errors is a
   concern.

7.  IANA Considerations

7.1.  Parameter Problem codes

   IANA is requested to assign the following codes for ICMPv6 type 4
   "Parameter Problem" [IANA-PARAMPROB]:

      *  Unrecognized Next Header type encountered by intermediate node
         (value TBA1)

      *  Extension header too big (value TBA2)

      *  Extension header chain too long (value TBA3)

      *  Too many extension headers (value TBA4)

      *  Too many options in extension header (value TBA5)

      *  Option too big (value TBA6)




Herbert                Expires September 19, 2020              [Page 13]


Internet-Draft                ICMPv6 limits                   March 2020


7.2.  Destination Unreachable codes

   IANA is requested to assign the following code for ICMPv6 type 1
   "Destination Unreachable" [IANA-DESTUNREACH]:

      *  Headers too long (value TBA7)

7.3.  ICMP Extension Object Classes and Class Sub-types

   IANA is requested to assign the following Class value in the "ICMP
   Extension Object Classes and Class Sub-types" registry [IANA-
   ICMPEXT]:

      *  Extended information (value TBA8)

   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.

   IANA is requested to assign the following Sub-type within the
   "Extended information" ICMP extension object class:

      *  Pointer (value TBA9)

8.  Acknowledgments

   The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard,
   Michael Richardson, Mark Smith, Suresh Krishnan, and Ole Tran for
   their comments and suggestions that improved this document.

9.  References

9.1.  Normative References

   [IANA-DESTUNREACH]
              "Internet Control Message Protocol version 6 (ICMPv6)
              Parameters, Type 1 - Destination Unreachable",
              <https://www.iana.org/assignments/icmpv6-parameters/
              icmpv6-parameters.xhtml#icmpv6-parameters-codes-2>.

   [IANA-ICMPEXT]
              "ICMP Extension Object Classes and Class Sub-types",
              <https://www.iana.org/assignments/icmp-parameters/icmp-
              parameters.xhtml#icmp-parameters-ext-classes>.






Herbert                Expires September 19, 2020              [Page 14]


Internet-Draft                ICMPv6 limits                   March 2020


   [IANA-PARAMPROB]
              "Internet Control Message Protocol version 6 (ICMPv6)
              Parameters, Type 4 - Parameter Problem",
              <https://www.iana.org/assignments/icmpv6-parameters/
              icmpv6-parameters.xhtml#icmpv6-parameters-codes-5>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
              DOI 10.17487/RFC4884, April 2007, <https://www.rfc-
              editor.org/info/rfc4884>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013, <https://www.rfc-
              editor.org/info/rfc7045>.

   [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>.

9.2.  Informative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-26 (work in
              progress), October 2019.

   [I-D.ioametal-ippm-6man-ioam-ipv6-options]
              Bhandari, S., Brockners, F., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B.,
              Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati,
              "In-situ OAM IPv6 Options", draft-ioametal-ippm-6man-ioam-
              ipv6-options-02 (work in progress), March 2019.





Herbert                Expires September 19, 2020              [Page 15]


Internet-Draft                ICMPv6 limits                   March 2020


   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <https://www.rfc-editor.org/info/rfc4821>.

   [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
              ICMPv6 Messages in Firewalls", RFC 4890,
              DOI 10.17487/RFC4890, May 2007, <https://www.rfc-
              editor.org/info/rfc4890>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017, <https://www.rfc-
              editor.org/info/rfc8305>.

   [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

   Tom Herbert
   Intel
   Santa Clara, CA
   USA

   Email: tom@quantonium.net

























Herbert                Expires September 19, 2020              [Page 16]