



Network Working Group                                         T. Herbert
Internet-Draft                                                    XDPnet
Intended status: Standards Track                         4 November 2025
Expires: 8 May 2026


                     Scale-Up Network Header (SUNH)
                         draft-herbert-sunh-00

Abstract

   This document specifies a network header that is a type of compressed
   IPv4 or IPv6 header.  The use case is high performance networking in
   limited domains, in particular in scale-up networks for AI where even
   modest packet overhead packet may be materially detrimental to
   overall performance.  The SUNH network header provides three primary
   benefits: 1) It reduces the amount of on-the-wire protocol overhead,
   2) It simplifies route lookup to be more efficient with lower
   latency, 3) It retains the properties and benefits of a Network Layer
   header including compatibility with deployed Ethernet switches and
   NICs.

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 https://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 8 May 2026.

Copyright Notice

   Copyright (c) 2025 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



Herbert                    Expires 8 May 2026                   [Page 1]

Internet-Draft                    SUNH                     November 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem statement . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Prior work: Scale-Up Ethernet approach  . . . . . . . . .   3
     1.3.  Introducing Scale-Up Network Header . . . . . . . . . . .   4
     1.4.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Design and Requirements . . . . . . . . . . . . . . . . . . .   4
     2.1.  SUNH domains and EtherType  . . . . . . . . . . . . . . .   5
     2.2.  Switching and Routing . . . . . . . . . . . . . . . . . .   5
     2.3.  SUNH Domains and VLANs  . . . . . . . . . . . . . . . . .   6
   3.  SUNH Format . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Host requirements . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  SUNH domains  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Encapsulation in SUNH . . . . . . . . . . . . . . . . . .   7
     4.3.  TCP and UDP in SUNH . . . . . . . . . . . . . . . . . . .   8
     4.4.  IPv6 extension headers and SUNH . . . . . . . . . . . . .   8
     4.5.  Minimum packet length . . . . . . . . . . . . . . . . . .   9
       4.5.1.  SUNH payload is greater than thirty-eight bytes . . .   9
       4.5.2.  The SUNH payload has self-describing length . . . . .   9
       4.5.3.  Explicit padding  . . . . . . . . . . . . . . . . . .   9
     4.6.  Receiver processing . . . . . . . . . . . . . . . . . . .  11
     4.7.  ICMP errors . . . . . . . . . . . . . . . . . . . . . . .  11
     4.8.  Flow hash . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Router requirements . . . . . . . . . . . . . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

1.1.  Problem statement

   AI and Machine Learning are pushing networking requirements to
   stratospheric levels of performance.  This is especially true in so
   called "scale-up networks for AI" which consist of clusters of
   tightly coupled GPUs or generically XPUs.  The performance
   requirements include multi-terabits of throughput and latencies
   measured in the tens of nanoseconds.  Some traffic patterns may have
   a majority of small packets, like for KVcache in AI, where packet



Herbert                    Expires 8 May 2026                   [Page 2]

Internet-Draft                    SUNH                     November 2025


   sizes may commonly be 256 bytes or less.  For traditional network
   layers, including IPv4 and IPv6, network headers are appreciable
   protocol overheard and can reduce throughput in high performance
   scenarios.  For instance, the twenty byte header of IPv4 represents
   about 8% overhead in a 256 byte packet, and the forty bytes of IPv6
   header would be about 16% overhead.

   In addition to the problems of per packet overhead, there is also the
   cost of looking up IP addresses for routing or matching addresses in
   table lookups.  Long addresses require CAMs, TCAMs, or tree
   mechanisms that increase latency and power consumption in routers.

1.2.  Prior work: Scale-Up Ethernet approach

   Scale-Up Ethernet, or SUE [SUE], is a proposal for a new Ethernet
   protocol for scale-up networks.  SUE addresses the network layer
   overheads by redefining the Ethernet header based on the Structured
   Local Address Plan in IEEE 802.c-2017 [IEEE_802c-2017].  SUE defines
   two "AI Header Formats" for the Ethernet header: AHF Gen 1 and AHF
   Gen 2.  These formats turn the Ethernet header into a quasi network
   layer header.  AFH Gen 1 uses the standard Ethernet header format,
   however switching is performed only on the low order sixteen bits of
   the Ethernet addresses.  AF Gen 1 also allows a four byte shim header
   to follow the Ethernet header that contains pertinent network layer
   fields like Hop Limit and Traffic Class.  AFH Gen 2 repurposes the
   entire Ethernet header to contain sixteen bit addresses or thirty-two
   bit "XPU addresses" as well as Network Layer fields.

   The fundamental problem with the AI Header Formats in the SUE
   approach is that they're not compatible with deployed switches.  In
   order to properly forward AFH packets, switches must be updated
   specifically with new functionality.  The modifications are invasive
   since switches need to fundamentally reinterpret the Ethernet header.

   In addition to the creating incompatibility with legacy switches, AFH
   headers are also incompatible with deployed NICs.  When a NIC
   receives a packet it attempts to match the destination MAC address as
   being local.  Typically, this is done by an exact match CAM lookup on
   the forty-eight bit Destination MAC address.  For AFH, only a subset
   of bits in the forty-eight bit Destination address are valid so the
   normal CAM lookup will fail.  The only work around would be to place
   the NIC in Promiscuous mode and then match the XPU Destination
   address in software.








Herbert                    Expires 8 May 2026                   [Page 3]

Internet-Draft                    SUNH                     November 2025


1.3.  Introducing Scale-Up Network Header

   This document specifies the Scale-Up Network Header, or SUNH that is
   a compressed network header for IPv4 or IPv6.  It's a "scale-up
   protocol" since intended use cases are limited domains, such as
   scale-up networks for AI, where reducing packet overhead and protocol
   header complexity benefits performance.

   The primary difference between SUE's AFH format and SUNH is that SUNH
   is a proper Network Layer header.  Other than a new EtherType, SUNH
   is transparent to the Ethernet Header.  This means that SUNH is
   compatible with existing deployed Ethernet switches.  Layer 2
   switching "just works" with SUNH since only the Ethernet addresses
   are considered and they're not modified.  Layer 3 switching would
   work the same way that switches can switch IP packets based on IP
   addresses.  A Layer 3 switch could identify SUNH packets by
   EtherType, parse the SUNH header, perform route lookups on the SUNH
   destination address, and then forward the packet per Hop Limit,
   Traffic Class, and Flow Label fields in the SUNH header.

   The SUNH header may be used in lieu of an IPv4 or IPv6 header.  SUNH
   is an eight byte header so there is a substantial savings in protocol
   overhead compared to IPv4 or IPv6.  Additionally, SUNH addresses are
   sixteen bits in size that affords the use of very efficient route
   lookup techniques.

1.4.  Requirements Language

   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.  Design and Requirements

   We define the Scale-Up Ethernet Header, or SUNH, as a compressed IP
   header.  SUNH is an eight octet header.  The source and destination
   addresses are each sixteen bits (two octets).  The other four octets
   constitute a Next Header number, Hop Limit, Traffic Class, and a Flow
   Label.  Note that a compressed IPv4 or IPv6 header share the same
   format in SUNH.  Any interpretation of a SUNH header being a
   compressed IPv4 or IPv6 header is from domain local configuration and
   cannot be inferred from the SUNH header.







Herbert                    Expires 8 May 2026                   [Page 4]

Internet-Draft                    SUNH                     November 2025


2.1.  SUNH domains and EtherType

   SUNH only works within a limited domain [RFC8799] called a "SUNH
   domain".  Within the SUNH domain a "SUNH prefix" is defined.  This is
   the implied IPv4 or IPv6 prefix for host unicast addresses in the
   SUNH format.  A SUNH address is then the sixteen bit host part of a
   fully qualified IPv4 or IPv6 address.  If the SUNH prefix is IPv4
   then the prefix is sixteen bits or more, and for IPv6 the prefix is
   112 bits or more.  All participating nodes in a SUNH domain are
   configured with the common SUNH prefix and whether the SUNH header is
   a compressed IPv4 or IPv6 header.  A SUNH can be expanded to an full
   IPv4 or IPv6 address by appending the SUNH prefix to the SUNH
   address.

   SUNH is distinguished by its own EtherType when encapsulated in
   Ethernet.  For other Layer 2 technologies, an equivalent identifier
   may indicate SUNH is encapsulated.  Note that SUNH does not have an
   IP version number, any interpretation of a SUNH header as being a
   compressed IPv4 header or IPv6 header is local to nodes in a SUNH
   domain.  Additionally, the SUNH network might be not even be
   interpreted as a compressed IP header, and instead it may be treated
   as a separate network protocol.  As long as all nodes in the SUNH
   limited domain are agreement, such the interpretation of SUNH is
   consistent within the limited domain.

2.2.  Switching and Routing

   Other than defining a new EtherType, SUNH has no impact on the link
   layer.  SUNH packets may be Layer 2 switched by commodity switches
   since Layer 2 switching is based on solely Ethernet addresses such
   that the EtherType and Ethernet payload are transparent to the
   forwarding operation.

   A SUNH packet may be routed or Layer 3 switched.  In this case the
   router would be modified to understand and route SUNH packets.  The
   routing decision can be based entirely on the sixteen bit Destination
   Address, and there are no multicast or broadcast addresses.

   Because SUNH addresses are sixteen-bits, in a limited domain SUNH
   addresses could be assigned from a small range.  This potentially
   simplifies route lookup on addresses.  For instance, if all addresses
   were assigned from a ten bit host part, that is assigned SUNH
   addresses are in the range 0 to 1023, then a route lookup can be
   implemented with a simple array where the address is used to index
   the array.  This array could easily be in SRAM, so that route lookups
   degenerate to very fast indexed memory loads.





Herbert                    Expires 8 May 2026                   [Page 5]

Internet-Draft                    SUNH                     November 2025


2.3.  SUNH Domains and VLANs

   Multiple SUNH domains may be defined in a network using VLANs.  Each
   VLAN could be associated with its own SUNH domain.  A host may have
   SUNH addresses in different domains that are associated with
   different VLANs and Layer 3 switches would have forwarding tables for
   each VLAN that defines a SUNH domain.

3.  SUNH Format

   The SUNH header format is shown below, Note that definitions of the
   non-address fields are consistent with the analogous fields in the
   IPv6 header [RFC8200].

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Traffic Class |  Next Header  |HopLim |       Flow Label      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Source Address       |      Destination Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   Traffic Class
      8-bit Traffic Class field equivalent to the IPv6 Traffic Class
      field and has the same semantics.  The current use of the Traffic
      Class field for Differentiated Services and Explicit Congestion
      Notification is specified in [RFC2474] and [RFC3168].

   Next Header
      8-bit selector.  Identifies the type of header immediately
      following the SUNH header.  Uses the same values as the IPv4
      Protocol field [IANA-PN].

   HopLim
      4-bit integer Hop Limit field.  This is equivalent to the IPv6 Hop
      Limit field except that the SUNH Hop Limit is four bits.  The
      field value is decremented by 1 by each node that forwards the
      packet.  When forwarding, the packet is discarded if Hop Limit was
      zero when received or is decremented to zero.  A node that is the
      destination of a packet SHOULD NOT discard a packet with Hop Limit
      equal to zero; it SHOULD process the packet normally.

   Flow Label
      12-bit flow label.  This is a smaller version of the IPv6 Flow
      Label and is otherwise set and processed with the same semantics.




Herbert                    Expires 8 May 2026                   [Page 6]

Internet-Draft                    SUNH                     November 2025


   Source Address
      16-bit SUNH address of the originator of the packet.  Normally
      this is the host part of the uncompressed source IP address (IPv4
      or IPv6).

   Destination Address
      16-bit SUNH destination address of the intended recipient.
      Normally this is the host part of the uncompressed destination IP
      address (IPv4 or IPv6).

   Note that the SUNH header does not have a Total Length field or
   Payload Length field as IPv4 and IPv6 have.  The total length of the
   packet is determined from the length of the Layer 2 frame.  That is
   the last byte in a SUNH packet coincides with the last byte in an
   Ethernet packet for example.

4.  Host requirements

   The requirements for host with regard to SUNH are described below.

4.1.  SUNH domains

   A sender MUST only send a packet with an SUNH header if the SUNH
   domain prefix is properly configured and the destination is within
   the domain.  The SUNH source and destination addresses MUST be host
   unicast addresses (not multicast or broadcast).

   Nodes within a SUNH MAY use SUNH addresses as canonical endpoints.
   In this case SUNH addresses might not correspond to IP addresses, and
   all communications would be done only using SUNH as the network layer
   protocol.  If this interpretation is valid within a SUNH domain then
   all nodes MUST be configured with the same interpretation.

4.2.  Encapsulation in SUNH

   The SUNH Next Protocol MAY used with any IP protocol that is
   independent of the IP address format in the network header of the
   packet.  In other cases, the protocols may be used with adaption or
   prohibited as described below.


   A SUNH packet is constructed from an Ethernet header (or other Layer
   2 header), followed by a SUNH header, followed by an IP protocol
   (e.g.  TCP or UDP).  The EtherType in the Ethernet header MUST be set
   to the EtherType for SUNH (or the equivalent next protocol identifier
   in another Layer 2 protocol is set to indicate SUNH).





Herbert                    Expires 8 May 2026                   [Page 7]

Internet-Draft                    SUNH                     November 2025


4.3.  TCP and UDP in SUNH

   A SUNH header MAY encapsulate TCP or UDP.  The pseudo checksum for
   the TCP or UDP checksum includes the IPv4 or IPv6 addresses.  When
   TCP or UDP is encapsulated in SUNH a pseudo header with SUNH
   addresses MUST be used as shown below.

   The pseudo header for the UDP checksum with SUNH is:

           0         7 8       15 16      23 24       31
           +----------+----------+----------+----------+
           |    source address   | destination address |
           +----------+----------+----------+----------+
           |   zero   | protocol |     UDP length      |
           +----------+----------+----------+----------+

   The pseudo header for the TCP checksum with SUNH is:

           0         7 8       15 16      23 24       31
           +----------+----------+----------+----------+
           |    source address   | destination address |
           +----------+----------+----------+----------+
           |   zero   | protocol |     TCP length      |
           +----------+----------+----------+----------+

   Note that the TCP and UDP pseudo headers for SUNH are fewer bytes
   than that for IPv4 or IPv6, this does provide a minor performance
   benefit in calculating the pseudo header checksum.

4.4.  IPv6 extension headers and SUNH

   If the protocol of an uncompressed SUNH header is IPv6 then IPv6
   extension headers MAY be used as the Next Protocol in a SUNH header.
   An exception is that the Routing Header MUST NOT be used since
   routers are not expected to have SUNH addresses and even if they did
   then the IPv6 addresses in the segment list of a Routing Header are
   not compatible to set as the destination address in the SUNH.  In
   practice, not beng able to use Routing Headers with SUNH is no great
   loss, the major point of SUNH is to reduce protocol header overhead
   and the overhead of even a single Routing Header would nullify most
   of the benefits of SUNH.










Herbert                    Expires 8 May 2026                   [Page 8]

Internet-Draft                    SUNH                     November 2025


4.5.  Minimum packet length

   The minimum Ethernet frame size is sixty-four bytes which translates
   to a minimum Ethernet payload size of forty-six bytes.  Since SUNH
   does not have a total length or payload length like IPv4 and IPv6
   headers do, care must be taken to ensure the minimum packet size is
   maintained.

   There are three ways to ensure Ethernet frames have a proper minimum
   length.  These are described below.

4.5.1.  SUNH payload is greater than thirty-eight bytes

   If the SUNH payload is greater than or equal to thirty-eight bytes in
   length then the minimum frame length requirement is automatically
   satisfied.

   For this method a sender would just need to check that the SUNH
   payload is greater than or equal to thirty-eight bytes.  If the
   payload length is greater than or equal to thirty-eight bytes then no
   further action needs to be taken and the packet can be transmitted.

4.5.2.  The SUNH payload has self-describing length

   If the SUNH payload is less than thirty-eight bytes in size but the
   length of the SUNH payload can be unambiguously deduced from protocol
   headers in the payload, then the minimum length requirement is
   satisfied by padding the packet up to the minimum sixty-four byte
   frame length.

   An example of this case is a UDP packet encapsulated in SUNH (Next
   Protocol is 17).  The UDP header contains a UDP Length field that
   unambiguously gives the length of the SUNH payload.  For instance, if
   a UDP packet with minimum length of eight is encapsulated in a SUNH
   header then the total length of the Ethernet payload is sixteen
   bytes.  The packet is sent by padding it with thirty bytes (zeroes
   after the UDP header).

4.5.3.  Explicit padding

   If the SUNH payload is less than thirty-eight bytes in size and the
   the length cannot be deduced from the protocol headers in the SUNH
   payload, then explicit padding can be used.  The idea is to insert a
   Destination Option Extension Header after the SUNH header that
   contains a single PADN option [RFC8200].






Herbert                    Expires 8 May 2026                   [Page 9]

Internet-Draft                    SUNH                     November 2025


   An example of this case is TCP that unlike UDP does not have a
   payload length field in its header.  For instance, if a pure ACK were
   sent without any TCP options that would be a twenty byte header with
   no TCP payload.  When encapsulated in SUNH the length of the Ethernet
   payload is twenty-eight bytes which is eighteen bytes short of the
   minimum length.  Zero bytes cannot be padded to the packet since they
   would be interpreted as bytes of TCP payload.  In order to handle
   this case, explicit padding is inserted into the packet in the form
   of an IPv6 Destination option.

   The Destination option is set in an Destination Options extension
   header with one PADN option.  The number of bytes needed in the
   extension header is rounded up to be divisible by eight:

           #bytes = 8 * ((bytes_needed + 7) / 8)

   The extension header length and PADN option length are then set as:

           Extension header length = (#bytes / 8) - 1

           PADN option length = #bytes - 4

   For our example, the Destination Options extension header for padding
   a TCP packet with no TCP options and no TCP payload in SUNH header
   would be:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       6       |       2       |       1      |       20       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                          20 bytes of zeroes                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The next protocol field in the SUNH would be set to 60 to indicate a
   Destination Options header.  The Next Header field in the Destination
   Options header is set to 6 to indicate TCP.

   Note that a SUNH packet may already have extension headers.  In this
   case the Destination Options extension header can be inserted as
   another extension header after the SUNH header, unless a Hop-by-Hop
   Options is present then the Destination option must be inserted after
   the Hop-by-Hop options header.





Herbert                    Expires 8 May 2026                  [Page 10]

Internet-Draft                    SUNH                     November 2025


4.6.  Receiver processing

   A configured host receiver SHOULD accept SUNH packets.  Packets
   received with a SUNH EtherType are processed by the network layer.
   If the Destination Address matches the local SUNH per the applicable
   SUNH domain then the recipient is the intended receiver.  If a
   properly formatted SUNH packet is received to the local address, the
   Next Protocol is used to parse and process the next protocol.

   A receiver has two options for how to treat SUNH addresses
   internally:

   *  It may append the SUNH prefix and then perform internal processing
      as though the packet had been received to the uncompressed address
      (e.g. the TCP connection table uses plain IP addresses in
      connection tuples)

   *  The host MAY treat the packet as having different network layer
      state where protocol tuples include the SUNH addresses.  The
      latter case might be appropriate for a scale-up protocol with
      packets that are only ever sent in SUNH.

   The choice of option is specific to each SUNH domain.

4.7.  ICMP errors

   Hosts MAY send ICMP errors in response to a SUNH packet.  The ICMP
   message MUST be encapsulated in SUNH with the source and destination
   addresses swapped from the original packet.  The ICMP message format,
   ICMPv4 or ICMPv6, would correspond to the uncompressed SUNH protocol
   format (IPv4 or IPv6).

4.8.  Flow hash

   SUNH affords a very efficient mechanism to produce a flow hash for a
   packet that includes the addresses and Flow Label as input.  The
   procedures are (assuming sixty-four bit registers):

   1.  Load the eight byte SUN header into a register

   2.  "Or" the Traffic Class field with all ones

   3.  Run a hash function over the register

   The result of this process is a hash over the addresses, Flow Label,
   Next Header, and Hop Limit.  The Next Header is reasonable input
   since it's expected that a host would normally send all packets with
   for a Transport Layer flow with the same Next Header.  The Hop Limit



Herbert                    Expires 8 May 2026                  [Page 11]

Internet-Draft                    SUNH                     November 2025


   is reasonable to include since we normally expect that packets of the
   same flow will have the same Hop Limit when received by some node on
   the network (although the Hop Limit seen for a flow could differ
   between nodes but that's not a problem).

5.  Router requirements

   A router MAY support routing (or Layer 3 switching) of SUNH packets.
   The basic idea is that the router performs route lookup on the SUNH
   destination address to get next hop information and then forwards the
   packet accordingly.

   A router forwards a SUNH packet solely base on the contents of the
   Ethernet and SUNH headers.  The router SHOULD NOT parse the SUNH
   payload.  If a router is performing ECMP routing then it SHOULD use
   the SUNH Flow Label for flow entropy input, and it SHOULD NOT parse
   beyond the SUNH header to extract information from the transport
   layer headers (i.e. a router should not use transport port numbers as
   flow entropy input).

   A router processes the Hop Limit field in expected fashion.  When a
   router receives a SUNH packet, the Hop Limit is checked.  If the Hop
   Limit is zero or one then the packet is discarded and an "ICMP Time
   Exceeded" error MAY be sent in response.  If the router forwards the
   packet then the non-zero hop limit is decremented.

6.  IANA Considerations

   There are no actions required for IANA defined in this document.

7.  Security Considerations

   SUNH is expressly a limited domain protocol meaning that packets with
   the SUNH protocol should be constrained to the networks of the SUNH
   domain.  This can be accomplished via a firewall that blocks packets
   with the SUNH EtherType from crossing the domain boundary.

   As a network layer protocol SUNH does not introduce any new security
   concerns.  It would have similar concerns to those of IPv4 or IPv6.

8.  References

8.1.  Normative References

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



Herbert                    Expires 8 May 2026                  [Page 12]

Internet-Draft                    SUNH                     November 2025


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

8.2.  Informative References

   [IANA-PN]  "Assigned Internet Protocol Numbers",
              <https://www.iana.org/assignments/protocol-numbers/
              protocol-numbers.xhtml>.

   [IEEE_802c-2017]
              "IEEE 802c-2017: IEEE Standard for Local and Metropolitan
              Area Networks:Overview and Architecture--Amendment 2:
              Local Medium Access Control (MAC) Address Usage", June
              2017, <https://standards.ieee.org/ieee/802c/6890/>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

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

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [SUE]      "Scale-Up Ethernet Framework", September 2025,
              <https://docs.broadcom.com/doc/scale-up-ethernet-
              framework>.

Author's Address

   Tom Herbert
   XDPnet
   Los Gatos, CA,
   United States of America
   Email: tom@herbertland.com




Herbert                    Expires 8 May 2026                  [Page 13]
