RFC 8883

ICMPv6 Errors for Discarding Packets Due to Processing Limits

📅 published September 2020, from ietf

RFC 8883: ICMPv6 Errors for Discarding Packets Due to Processing Limits ✨

Part 1 of 3 🎀

Author: T. Herbert (Intel) 💖 Category: Standards Track 🦋 Date: September 2020 🌸 ISSN: 2070-1721 Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates 🫶 Published by: Internet Engineering Task Force (IETF) 🌈

Abstract 💅

okay so network nodes can throw packets away when they can't get through the protocol headers, because they're hitting processing limits 😭. The sender gets zero info about it, so they can't fix whatever caused the drop. This spec adds a bunch of new ICMPv6 errors that a node can send when it's tossing a packet because it can't process those headers 🔥. A node that gets one of these errors can use the info to figure out why packets are disappearing, and it can change what it sends later so the drops stop happening 👑.

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🎀.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8883 🔗.

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) as they're in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no 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 doc specifies a bunch of new ICMPv6 errors that a node can send when it discards a packet because it can't process the necessary protocol headers due to processing constraints or limits 🌟. These are new ICMPv6 code points that add to the ones already defined in [RFC4443]. Six of the errors are for extension header processing, and one more is for when the combined protocol headers in a packet go over a node's processing limits 🦋.

1.1. Extension Header Limits ✨

In IPv6, optional internet-layer info rides along in one or more IPv6 extension headers [RFC8200] 🎀. Extension headers sit between the IPv6 header and the upper-layer header in a packet. "Header chain" is the collective term for the IPv6 header, the extension headers, and the upper-layer headers in a packet 🔗. Each individual extension header can be up to 2048 octets long and has to fit into a single packet 📦. Destination Options and Hop-by-Hop Options hold a list of options in type-length-value (TLV) format 💜. Every option has a length for its data field, in octets: the smallest option (non-pad type) is two octets, and the biggest is 257 octets 🌸. The number of options in an extension header is only capped by the header's length and the Path MTU from source to destination 😭. A receiver can skip over options it doesn't recognize if the Option Type says it's okay to skip (the first two high-order bits are 00) 🧚.

Per [RFC8200], extension headers, apart from Hop-by-Hop Options, aren't examined or processed by intermediate nodes 💅. Still, in real deployed networks, plenty of intermediate nodes do look at extension headers for all kinds of reasons 👀. For example, a node might check every extension header to find the transport header of a packet so it can do transport-layer filtering, or track connections for a stateful firewall 🔥.

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

Extension headers can be variable-length, really long, or a potential denial-of-service attack, so a lot of devices put operational limits on the extension headers in the packets they handle 😭. [RFC7045] talks about what intermediate nodes need to do when they discard packets because of unrecognized extension headers 🙈. [RFC8504] covers limits that might be applied to the number of options in Hop-by-Hop Options or Destination Options extension headers 💖. Both intermediate nodes and end hosts can put limits on extension header processing. When a limit gets exceeded, the usual behavior is to silently discard the packet 🫠.

This spec defines six Parameter Problem codes that a node can send when it discards a packet because it went over the extension header processing limits 🎀. The info in these ICMPv6 errors can help with diagnostics, so you can figure out why packets are getting dropped 🔍. Also, a source node that gets these errors might be able to change how it uses extension headers in later packets to the same destination, so it stops getting packets discarded 🦋.

1.2. Aggregate Header Limits 🌷

Some hardware devices have a fixed-size parsing buffer for processing packets 🧩. The buffer is supposed to hold all the headers a device needs to look at (often up to a transport-layer header, for filtering) 🔧. If the total length of the headers in a packet is bigger than the parsing buffer, the device will either discard the packet or push the work to a software slow path 🐢. Either way, no sign of the problem goes back to the sender 😭.

This document defines one ICMPv6 Destination Unreachable code, which a node sends when it can't process a packet's headers because their combined size is over a processing limit 🌸. The info in this ICMPv6 error can help with diagnostics, so you can see why packets are being dropped 🔍. Also, a source node that gets this error might be able to change the headers it uses in later packets to avoid more drops 💜.

1.3. Nonconformant Packet Discard 🙈

The ICMP errors in this spec might apply to cases where a node drops packets outside of any standard spec 🫣. For example, an intermediate node might send a "Headers too long" code when it drops a packet because it can't parse deeply enough to get the transport-layer info it needs for packet filtering 🧐. That kind of behavior might be considered nonconformant (with respect to [RFC8200], for example) 🚨.

This spec doesn't promote behaviors that might be considered nonconformant 🙅‍♀️. But packet discard really does happen in real deployments, and this spec's whole point is to give visibility into why packets are being discarded 👀. The spirit here is that giving some reason is way better than a silent drop, so sending ICMP errors is RECOMMENDED, even in cases where a node might be discarding packets because of 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" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 🎀.

2. ICMPv6 Errors for Extension Header Limits 🦋

Six new codes are defined for the Parameter Problem type ✨.

2.1. Format 🧾

The ICMPv6 Parameter Problem message [RFC4443] for an extension header limit exceeded error looks like this 👇:

 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: whatever's pertinent to this spec 🫶. Here's the lineup:
          +----+----------------------------------+
          | 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: tells you the octet offset within the invoking packet where the problem happened 🎯.

The pointer will point beyond the end of the IPv6 packet if the field that went over the limit is too far in to fit within the max size of an ICMPv6 error message 📏. If you're going to use the pointer as an offset to read the data in the invoking packet, a node MUST validate first 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) 🛣️

okay bestie, this one is for the middle routers doing the heavy lifting 📦. An intermediate node SHOULD send this code when it discards a packet because it runs into a Next Header type that it doesn't recognize during its examination. The ICMPv6 Pointer field is set to the offset of that unrecognized Next Header value within the original packet.

Quick note: this code is for intermediate nodes, so it SHOULD NOT be sent by a final destination 🙅‍♀️. If a final destination spots an unrecognized header, it SHOULD send an ICMP Parameter Problem message instead, 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 the code for "Extension header too big" SHOULD be sent when a node discards a packet because the size of an extension header goes over its processing limit 📏. The ICMPv6 Pointer field is set to the offset of the first octet in that extension header that exceeds the limit ✨.

2.4. Extension Header Chain Too Long (Code 7) 🔗

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

2.5. Too Many Extension Headers (Code 8) 🧚

An ICMPv6 Parameter Problem with the code for "Too many extension headers" SHOULD be sent when a node discards a packet whose extension header chain has more extension headers than the limit allows 🫶. 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 the code for "Too many options in extension header" SHOULD be sent when a node discards a packet with an extension header that has more options than the node's processing limits allow 🍓. This code applies to 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 the code for "Option too big" gets sent in two different situations 🙈. The first is when a single Hop-by-Hop or Destination Option is longer than a limit. The second is when the length or the number of consecutive Hop-by-Hop or Destination padding options goes over a limit.

If an option's length goes over a processing limit, the ICMPv6 Pointer field is set to the offset of the first octet of that option. If the length or number of padding options goes over a limit, the ICMPv6 Pointer field is set to the offset of the first octet of the padding option that exceeds the limit 🧩.

Possible padding limits 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 💜

There is one code defined for the Destination Unreachable type for aggregate header limits 🎯.

This ICMP error can apply to other headers in a packet too, not just the IPv6 header or the IPv6 extension headers 🌍. That's why a Destination Unreachable type with a multi-part ICMPv6 message format is used instead of the Parameter Problem type, which only covers errors about IPv6 headers 🙌.

3.1. Format 🧾

The error for aggregate header limits uses a multi-part ICMPv6 message format, as defined in [RFC4884] ✨. The extension object class "Extended Information" is defined to hold objects for extra information about an ICMP Destination Unreachable error. Inside that class, the sub-type "Pointer" is defined, and it has a Pointer field with similar meaning to the Pointer field in ICMP Parameter Problem errors 🦋.

The ICMPv6 message for an exceeded aggregate header limit looks like this:

 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                            | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

Here's what each field means 📚:

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 going over 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 that exceeds the limit is beyond what can fit in the maximum size of an ICMPv6 error message with the ICMP extension 👀. If you're using the pointer as an offset to read data in the invoking packet, 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 the code for "Headers too long" SHOULD be sent when a node discards a packet because the aggregate length of the headers in the packet goes over the node's processing limits 📦. The Pointer in the extended ICMPv6 structure is set to the offset of the first octet that exceeds the limit 🎯.

This error gets sent when a node drops a packet because the aggregate header chain is over its processing limits 🙅‍♀️. The aggregate header chain can include protocol headers other than the IPv6 header and IPv6 extension headers. For example, if a node is parsing a UDP encapsulation protocol, the encapsulating UDP header counts as part of the aggregate header chain 🫧.

As noted in Section 4.1, the ICMPv6 Destination Unreachable error with the code for "Headers too long" has the lowest precedence of the ICMP errors discussed in this specification 📉. If a packet contains an error that corresponds to a Parameter Problem code, a node SHOULD send the Parameter Problem error instead of the ICMPv6 Destination Unreachable error with the code for "Headers too long" 💅.

4. Operation ⚙️

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

4.1. Priority of Reporting 🥇

More than one ICMPv6 error might apply when reporting on a packet 👯. For example, the number of extension headers in a packet might go over a limit, and the aggregate length of protocol headers might also go over a limit. Only one ICMPv6 error SHOULD be sent for a packet, so a priority is defined to decide which error gets reported 🏆.

The RECOMMENDED reporting priority of ICMPv6 errors for processing limits goes 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 that the ICMPv6 error is valid and then take appropriate action, as suggested below 🕵️‍♀️.

The general validations for ICMP described in [RFC4443] apply here 💅. 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 specific to the upper layers may be performed, and they are out of scope for this specification 🌷.

The ICMPv6 error SHOULD be logged with enough detail to debug packet loss 📝. The details of the error, including the addresses and the offending extension header or data, should be retained 🗂️. This is super useful for debugging when a node is misconfigured and unexpectedly discarding packets, or when a new extension header is being rolled out 🧠.

A host MAY change how it uses protocol headers in later 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 end communications if extension headers are required, stop using extension headers in packets to the destination named in the ICMPv6 error, or try to change 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 isn't required for communication, the host may either stop sending it or change how it's used in later packets sent to the destination named in the ICMPv6 error 🌈.

5. Applicability and Use Cases ✨

5.1. Reliability of ICMP

okay bestie, real talk: ICMP is fundamentally unreliable 💀 and in real deployments it can straight up keep failing over some paths 😭. So like with any other use of ICMP, the errors in this doc are only best effort to deliver 🫶. No protocol should be built to rely on ICMP messages arriving reliably, not it 🙅‍♀️. If needed, you can bring in other mechanisms to help figure out why packets are getting tossed 🔍. For example, ICMP errors may be correlated with info from Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] or Happy Eyeballs for IPv6 [RFC8305]. How those alternative mechanisms interact is out of scope for this spec, so that's a different queen's problem 👑.

5.2. Processing Limits

this section is all about the trends and motivations behind processing limits that are actually worth sending ICMP errors for ✨.

5.2.1. Long Headers and Header Chains

the trend toward longer, more complex headers and header chains is something both end nodes and intermediate nodes have to deal with 🧚, and it's being driven by:

  • Deep packet inspection getting way more common in middleboxes 🕵️‍♀️. Lots of intermediate nodes now parse network-layer encapsulation protocols or transport-layer protocols.
  • Routing headers being deployed 🛣️. For example, [RFC8754] defines an extension header format with a list of IPv6 addresses, and that can eat up a considerable number of bytes.
  • In situ OAM headers that gather a rich set of measurements in the data path 📊. The tradeoff is extra 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 put limits on processing extension headers, as described in [RFC8504] 💻. Host implementations are usually software stacks, and those typically don't have any inherent processing limitations. When a software stack does impose limits, they're more likely there for denial-of-service mitigation or performance 🛡️.

5.2.3. At Intermediate Nodes

hardware devices that process packet headers can have limits on how many headers or how many bytes of headers they can handle 🔧. For instance, a middlebox hardware implementation might have a parsing buffer holding some number of bytes of packet headers to process. Parsing buffers usually have a fixed size, like 64, 128, or 256 bytes 📏. On top of that, hardware implementations (and some software ones) often don't have loop constructs 🙈. So processing a TLV list might be implemented as an unrolled loop, which means only a limited number of TLVs can get processed 💅.

6. Security Considerations

the security considerations for ICMPv6 described in [RFC4443] apply here 🔐. The ICMP errors described in this document MAY be filtered by firewalls in accordance with [RFC4890].

In some circumstances, sending ICMP errors could conceptually be exploited as a way to covertly figure out the processing capabilities of nodes 👀. That's a big deal, so an implementation SHOULD allow a configurable policy that withholds sending 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, and 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

8.2. Informative References

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

📦 where this page comes from