diff options
Diffstat (limited to 'doc/rfc/rfc8883.txt')
| -rw-r--r-- | doc/rfc/rfc8883.txt | 766 |
1 files changed, 766 insertions, 0 deletions
diff --git a/doc/rfc/rfc8883.txt b/doc/rfc/rfc8883.txt new file mode 100644 index 0000000..6c4d24e --- /dev/null +++ b/doc/rfc/rfc8883.txt @@ -0,0 +1,766 @@ + + + + +Internet Engineering Task Force (IETF) T. Herbert +Request for Comments: 8883 Intel +Category: Standards Track September 2020 +ISSN: 2070-1721 + + + ICMPv6 Errors for Discarding Packets Due to Processing Limits + +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 is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8883. + +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 + (https://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 + 1.1. Extension Header Limits + 1.2. Aggregate Header Limits + 1.3. Nonconformant Packet Discard + 1.4. Terminology + 2. ICMPv6 Errors for Extension Header Limits + 2.1. Format + 2.2. Unrecognized Next Header Type Encountered by Intermediate + Node (Code 5) + 2.3. Extension Header Too Big (Code 6) + 2.4. Extension Header Chain Too Long (Code 7) + 2.5. Too Many Extension Headers (Code 8) + 2.6. Too Many Options in Extension Header (Code 9) + 2.7. Option Too Big (Code 10) + 3. ICMPv6 Error for Aggregate Header Limits + 3.1. Format + 3.2. Usage + 4. Operation + 4.1. Priority of Reporting + 4.2. Host Response + 5. Applicability and Use Cases + 5.1. Reliability of ICMP + 5.2. Processing Limits + 5.2.1. Long Headers and Header Chains + 5.2.2. At End Hosts + 5.2.3. At Intermediate Nodes + 6. Security Considerations + 7. IANA Considerations + 7.1. Parameter Problem Codes + 7.2. Destination Unreachable Codes + 7.3. ICMP Extension Object Classes and Class Sub-types + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgments + Author's Address + +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 the + 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. However, in + deployed networks, many intermediate nodes 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 a + 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. + + This specification defines six Parameter Problem codes that may be + sent by a node that discards a packet due to the processing limits of + extension headers being exceeded. The information in these ICMPv6 + errors may be 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 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 in 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 a case where it drops a packet + because it is unable to parse deeply enough to extract the 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 to provide + visibility as to why packets are being discarded. In the spirit that + providing some reason is better than a silent drop, the sending of + ICMP errors is RECOMMENDED even in cases where a node might be + discarding packets per a nonconformant behavior. + +1.4. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +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 the 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) + + +----+----------------------------------+ + | 5 | Unrecognized Next Header type | + | | encountered by intermediate node | + +----+----------------------------------+ + | 6 | Extension header too big | + +----+----------------------------------+ + | 7 | Extension header chain too long | + +----+----------------------------------+ + | 8 | Too many extension headers | + +----+----------------------------------+ + | 9 | Too many options in extension | + | | header | + +----+----------------------------------+ + | 10 | Option too big | + +----+----------------------------------+ + + Table 1 + + Pointer: + Identifies the octet offset within the invoking packet where + the problem occurred. + + The pointer will point beyond the end of the IPv6 packet if the + field exceeding the limit is beyond what can fit in the maximum + size of an ICMPv6 error message. 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 5) + + 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 6) + + 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 7) + + 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 the first octet beyond + the limit. + +2.5. Too Many Extension Headers (Code 8) + + 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 the first octet of the first extension header that is + beyond the limit. + +2.6. Too Many Options in Extension Header (Code 9) + + 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 exceeds 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 10) + + 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 a case where 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 cases where the + length or number of padding options exceeds a limit, the ICMPv6 + Pointer field is set to the offset of the 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 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 the 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. + +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 a 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 + | | P + ~ As much of the 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 + + Code: (pertinent to this specification) + 8 - Headers too long + + Length: + Length of the padded invoking packet data measured in 64-bit + words. The ICMP extension structure immediately follows the + padded invoking packet data. + + Invoking Packet: + Contains as much of the invoking packet as possible without the + ICMPv6 packet exceeding the minimum IPv6 MTU. The invoking + packet data MUST be zero padded to the nearest 64-bit boundary + [RFC4884]. If the original invoking packet did not contain 128 + octets, the invoking packet data 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: + 4 - Extended Information + + C-Type: + 1 - Pointer + + 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 + data 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 the 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. + + 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 listed 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" + + 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 misconfigured 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 headers or extension 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 + +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 + the 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 be employed to augment the + processes used to deduce the reason that packets are being discarded. + For instance, ICMP error messages may be correlated with information + attained through Packetization Layer Path MTU Discovery (PLPMTUD) + [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, [RFC8754] 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 [OAM-IPV6]. + + * 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. + 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 64, 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 as a means to covertly deduce the processing + capabilities of nodes. Accordingly, an implementation SHOULD allow a + configurable policy to withhold sending of the ICMP errors described + in this specification in environments where the security of ICMP + errors is a concern. + +7. IANA Considerations + +7.1. Parameter Problem Codes + + IANA has assigned the following codes in the "Type 4 - Parameter + Problem" registry within the ICMPv6 Parameters registry [IANA-ICMP]: + + +======+==================================+ + | Code | Name | + +======+==================================+ + | 5 | Unrecognized Next Header type | + | | encountered by intermediate node | + +------+----------------------------------+ + | 6 | Extension header too big | + +------+----------------------------------+ + | 7 | Extension header chain too long | + +------+----------------------------------+ + | 8 | Too many extension headers | + +------+----------------------------------+ + | 9 | Too many options in extension | + | | header | + +------+----------------------------------+ + | 10 | Option too big | + +------+----------------------------------+ + + Table 2 + +7.2. Destination Unreachable Codes + + IANA has assigned the following code in the "Type 1 - Destination + Unreachable" registry within the ICMPv6 Parameters registry + [IANA-ICMP]: + + +======+==================+ + | Code | Name | + +======+==================+ + | 8 | Headers too long | + +------+------------------+ + + Table 3 + +7.3. ICMP Extension Object Classes and Class Sub-types + + IANA has assigned the following Class value in the "ICMP Extension + Object Classes and Class Sub-types" registry within the ICMP + Parameters registry [IANA-ICMPEXT]: + + +=============+======================+ + | Class Value | Class Name | + +=============+======================+ + | 4 | Extended Information | + +-------------+----------------------+ + + Table 4 + + IANA has created a sub-type registry for the "Extended Information" + ICMP extension object class. The registration procedure for this + registry is "Standards Action". The sub-type value of 0 is reserved; + values greater than zero may be assigned. + + IANA has assigned the following sub-type within the "Sub-types - + Class 4 - Extended Information" registry within the ICMP Parameters + registry: + + +=======+=============+ + | Value | Description | + +=======+=============+ + | 1 | Pointer | + +-------+-------------+ + + Table 5 + +8. References + +8.1. Normative References + + [IANA-ICMP] + IANA, "Internet Control Message Protocol version 6 + (ICMPv6) Parameters", + <https://www.iana.org/assignments/icmpv6-parameters/>. + + [IANA-ICMPEXT] + IANA, "Internet Control Message Protocol (ICMP) + Parameters", + <https://www.iana.org/assignments/icmp-parameters/>. + + [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>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [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>. + +8.2. Informative References + + [OAM-IPV6] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., + Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., + Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. + Smith, "In-situ OAM IPv6 Options", Work in Progress, + Internet-Draft, draft-ietf-ippm-ioam-ipv6-options-03, 18 + September 2020, <https://tools.ietf.org/html/draft-ietf- + ippm-ioam-ipv6-options-03>. + + [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>. + + [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., + Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header + (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, + <https://www.rfc-editor.org/info/rfc8754>. + +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. + +Author's Address + + Tom Herbert + Intel + Santa Clara, CA + United States of America + + Email: tom@quantonium.net |