Comments on <draft-ietf-6man-icmp-limits-04>

[Bob Hinden <[e-mail]>]

Tom,

A few other comments on the <draft-ietf-6man-icmp-limits-04>.

Mostly editorial, a few questions.

Thanks,
Bob


> 
> 
> 
> 
> INTERNET-DRAFT                                                T. Herbert
> Intended Status: Standard                                          Intel
> Expires: February 2020
> 
>                                                         August 6, 2019
> 
> 
>    ICMPv6 errors for discarding packets due to processing limits
>                    draft-ietf-6man-icmp-limits-04
> 
> 
> 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 ICMPv6 errors that can be sent by a node that

s/defines ICMPv6 errors/defines several new ICMPv6 errors/

>  discards packets because it is unable to process the protocol
>  headers. A node that receives such an ICMPv6 error may be able to
>  modify what it sends in future packets to avoid subsequent packet
>  discards.
> 
> Status of this Memo
> 
>  This Internet-Draft is submitted to IETF in full conformance with the
>  provisions of BCP 78 and BCP 79.
> 
>  Internet-Drafts are working documents of the Internet Engineering
>  Task Force (IETF), its areas, and its working groups.  Note that
>  other groups may also distribute working documents as
>  Internet-Drafts.
> 
>  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."
> 
>  The list of current Internet-Drafts can be accessed at
>  http://www.ietf.org/1id-abstracts.html
> 
>  The list of Internet-Draft Shadow Directories can be accessed at
>  http://www.ietf.org/shadow.html
> 
> 
> Copyright and License Notice
> 
>  Copyright (c) 2019 IETF Trust and the persons identified as the
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 1]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  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
>  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  . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    1.1 Extension header limits  . . . . . . . . . . . . . . . . . .  4
>    1.2 Aggregate header limits  . . . . . . . . . . . . . . . . . .  5
>  2  ICMPv6 errors for extension header limits . . . . . . . . . . .  5
>    2.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
>    2.2 Unrecognized Next Header type encountered (code 1) . . . . .  6
>    2.3 Extension header too big (code 4)  . . . . . . . . . . . . .  6
>    2.4 Extension header chain too long (code 5) . . . . . . . . . .  7
>    2.5 Too many options in extension header (code 6)  . . . . . . .  7
>    2.6 Option too big (code 7)  . . . . . . . . . . . . . . . . . .  7
>  3  ICMPv6 error for aggregate header limits  . . . . . . . . . . .  8
>    3.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
>    3.2 Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
>  4  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
>    4.1 Priority of reporting  . . . . . . . . . . . . . . . . . . .  9
>    4.2 Host response  . . . . . . . . . . . . . . . . . . . . . . . 10
>  5  Applicability and use cases . . . . . . . . . . . . . . . . . . 11
>    5.1 Nonconformant packet discard . . . . . . . . . . . . . . . . 11
>    5.2 Reliability of ICMP  . . . . . . . . . . . . . . . . . . . . 11
>    5.3 Processing limits  . . . . . . . . . . . . . . . . . . . . . 11
>      5.3.1 Long headers and header chains . . . . . . . . . . . . . 11
>      5.3.2 At end nodes . . . . . . . . . . . . . . . . . . . . . . 12
>      5.3.3 At intermediate nodes  . . . . . . . . . . . . . . . . . 12
>  6  Security Considerations . . . . . . . . . . . . . . . . . . . . 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
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 2]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 3]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
> 1  Introduction
> 
>  This document specifies ICMPv6 errors that can be sent when a node

s/defines ICMPv6 errors/defines several new ICMPv6 errors/

>  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 as an update to [RFC4443]. Five 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 length of 2048 octets and must fit into

s/a length/a maximum length/

>  one MTU. Destination Options and Hop-by-Hop Options contain a list of

s/one MTU/a single packet/

>  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 MTU. Options may be skipped over

s/and MTU/and the Path MTU from the source to the destination/

>  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 header 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 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.
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 4]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  This specification defines four Parameter Problem codes and extends
>  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
>  exceeded. A source host that receives an ICMPv6 error may 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
> 
>  Many hardware devices implement a parsing buffer of a fixed size to

Many?   Perhaps “Some” would be better.

>  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 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. A source host that receives an ICMPv6 error can
>  modify the headers used in subsequent packets to try to avoid further
>  occurrences of packets being discarded or relegated to a slow path.
> 
> 2  ICMPv6 errors for extension header limits
> 
>  Four new codes are defined for the Parameter Problem type and
>  applicability of one existing code is extended for ICMPv6 errors for
>  extension header limits.
> 
> 2.1 Format
> 
>  The format of the ICMPv6 message for an extension header limit

Add reference to RFC4443 here.

>  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 [IPv6]           |
> 
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 5]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  IPv6 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)

This shows a mix of existing (1) and new Codes.   Please show the new ones as TBA (Too be Assigned) and have the IANA assigned ones replace the TBA when the RFC is published.

>        1 - Unrecognized Next Header type encountered
>        4 - Extension header too big
>        5 - Extension header chain too long
>        6 - Too many options in extension header
>        7 - Option too big
> 
>     Pointer
>        Identifies the octet offset within the invoking packet where
>        the problem occurred.
> 
>        The pointer will point beyond the end of the ICMPv6 packet if
>        the field having a problem is beyond what can fit in the
>        maximum size of an ICMPv6 error message.
> 
> 2.2 Unrecognized Next Header type encountered (code 1)
> 
>  [RFC8200] specifies that a destination host should send an
>  "unrecognized next header type" when a Next Header value is
>  unrecognized in a packet. This document extends this to allow
>  intermediate nodes to send this same error for a packet that is
>  discarded because the node does not recognize a Next Header type.
> 
>  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 when the original sender receives the ICMPv6 error it can
>  differentiate between the message being sent by a destination host,
>  per [RFC4443], and an error sent by an intermediate host based on
>  matching the source address of the ICMPv6 packet and the destination
>  address of the packet in the ICMPv6 data.
> 
> 2.3 Extension header too big (code 4)
> 
>  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
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 6]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  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 5)
> 
>  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 its processing limits.
> 
>  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
>  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
>  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
>  the offset of first octet of the first extension header that is
>  beyond the limit.
> 
> 2.5 Too many options in extension header (code 6)
> 
>  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.6 Option too big (code 7)
> 
>  An ICMPv6 Parameter Problem with code for "option too big" is sent in
>  two different cases: when the length of an individual option exceeds
>  a limit, or when the length or number of consecutive padding options
>  exceeds a limit.
> 
>  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
>  ICMPv6 Parameter Problem with code equal to 7. The ICMPv6 Pointer
>  field is set to the offset of the first octet of the option that
>  exceeds the limit.
> 
>  If a packet is discarded because the length or number of consecutive
>  padding options (PAD1 and PADN) exceeds a limit, a node SHOULD send
>  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
>  option that exceeds the limit.
> 
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 7]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  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.

[Comments on this section sent earlier.]

> 
> 3.1 Format
> 
>  The error for aggregate header limits employs a multi-part ICMPv6
>  message format as defined in [RFC4884]. The extended structure
>  contains a pointer to the first octet beyond the limit.
> 
>  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             |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |     unused    |    Length     |           unused              |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |      Internet Header + leading octets of original datagram    |
>  |                                                               |
>  |                           //                                  |
>  |                                                               |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                            Pointer                            |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>  IPv6 Fields:
> 
>     Destination Address
>        Copied from the Source Address field of the invoking packet.
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 8]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  ICMPv6 Fields:
> 
>     Type
>        1 (Destination Unreachable type)
> 
>     Code (pertinent to this specification)
>        8 - Headers too long

Change to TBA as above.

> 
>     Length
>        Length of the "original datagram" measured in 64 bit words
> 
>     Pointer
>        Identifies the octet offset within the invoking packet where a
>        limit was exceeded.
> 
>        The pointer will point beyond the end of the original datagram
>        if the field exceeding the limit is beyond what can fit in the
>        maximum size of an ICMPv6 error message.
> 
> 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.
> 
> 4  Operation
> 
>  Nodes that send or receive ICMPv6 errors due to header processing
>  limits MUST generally 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) Real error (existing codes)
> 
>     2) "Unrecognized Next Header type" encountered by an intermediate
>        node
> 
> 
> 
> T. Herbert              Expires February 7, 2020                [Page 9]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>     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" for number of extension
>        headers exceeding a limit
> 
>     8) "Extension header chain too long" for size of an extension
>        header chain exceeding a limit
> 
>     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
>  an appropriate action.

Should this be s/an appropriate action/an appropriate action as defined below/  or something else?

>  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 modify its
>       use of extension headers or headers to avoid further packet
>       discards.
> 
> 
> 
> T. Herbert              Expires February 7, 2020               [Page 10]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>     * A host system SHOULD take appropriate action if it is
>       automatically inserting extension headers into packets 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.

Could this be

 “… if it is creating packets with extension headers on behalf of the application”.

That would avoid the “inserting” issue and “automatically” that I don’t understand.


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


Note: regarding non-conformant implementations, I am doubtful they will be updated to support this.   I don’t object to trying, but not sure it will work in practice.


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

Does this paragraph say anything that isn’t already in the RFC4443?

> 
> 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
> 
> 
> 
> T. Herbert              Expires February 7, 2020               [Page 11]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  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
>  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 for denial of service attack or as a means to covertly
> 
> 


> 
> T. Herbert              Expires February 7, 2020               [Page 12]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  deduce processing capabilities of nodes as a precursor to denial of
>  service attack. 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.
> 
> 
> T. Herbert              Expires February 7, 2020               [Page 13]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
> 7  IANA Considerations
> 

Please include links to the IANA registry that these should be assigned from.


> 7.1 Parameter Problem codes
> 
>  IANA is requested to assign the following codes for ICMPv6 type 4
>  "Parameter Problem":
> 
>        4 - Extension header too big
> 
>        5 - Extension header chain too long
> 
>        6 - Too many options in extension header
> 
>        7 - Option too big

Please rewrite and me it clear these are suggested values.   Only IANA can decide which values to assign.

> 
> 7.2 Destination Unreachable codes
> 
>  IANA is requested to assign the following codes for ICMPv6 type 1
>  "Destination Unreachable":
> 
>        8 - Headers too long
> 

ditto


> 8  Acknowledgments
> 
>  The author would like to thank Ron Bonica, Bob Hinden, Nick Hilliard,
>  Michael Richardson, Mark Smith, and Suresh Krishnan for their
>  comments and suggestions that improved this document.
> 
> 9  References
> 
> 9.1  Normative References
> 
>  [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
>            Control Message Protocol (ICMPv6) for the Internet Protocol
>            Version 6 (IPv6) Specification", RFC 4443, DOI
>            10.17487/RFC4443, March 2006, <http://www.rfc-
>            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
>            IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045,
>            December 2013, <http://www.rfc-editor.org/info/rfc7045>.
> 
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020               [Page 14]
> INTERNET DRAFT       draft-ietf-6man-icmp-limits-04       August 6, 2019
> 
> 
>  [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>.
> 
> 9.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>.
> 
>  [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>.
> 
>  [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
> 
>  Tom Herbert
>  Intel
>  Santa Clara, CA
>  USA
> 
> 
>  Email: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> T. Herbert              Expires February 7, 2020               [Page 15]
>