Network Working Group T. Herbert Internet-Draft XDPnet Intended status: Standards Track 16 January 2026 Expires: 20 July 2026 Scale-Up Network Header (SUNH) draft-herbert-sunh-01 Abstract This document specifies the Scale-Up Network Header that is a concise and efficient network layer header. The primary use case is high performance networking in limited domains, and in particular in scale-up networks for AI where even modest packet overhead packet may be detrimental to overall performance. 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 20 July 2026. Copyright Notice Copyright (c) 2026 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 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. Herbert Expires 20 July 2026 [Page 1] Internet-Draft SUNH January 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Scale-Up Ethernet approach . . . . . . . . . . . . . . . 3 1.3. Introducing Scale-Up Network Header . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Design and Requirements . . . . . . . . . . . . . . . . . . . 5 2.1. SUNH domains . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SUNH EtherType . . . . . . . . . . . . . . . . . . . . . 6 2.3. Interpretation of a SUNH header . . . . . . . . . . . . . 6 2.3.1. SUNH as a standalone network layer header . . . . . . 6 2.3.2. SUNH as a compressed IP header . . . . . . . . . . . 6 2.4. Switching and Routing . . . . . . . . . . . . . . . . . . 7 2.5. SUNH Domains and VLANs . . . . . . . . . . . . . . . . . 7 3. SUNH Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Common prefix . . . . . . . . . . . . . . . . . . . . . . 7 3.2. SUNH with 8-bit addresses . . . . . . . . . . . . . . . . 8 3.3. SUNH with 16-bit addresses . . . . . . . . . . . . . . . 9 3.4. SUNH with 24-bit addresses . . . . . . . . . . . . . . . 9 3.5. SUNH with 32-bit addresses . . . . . . . . . . . . . . . 10 4. Host requirements . . . . . . . . . . . . . . . . . . . . . . 11 4.1. SUNH domains . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Encapsulation in SUNH . . . . . . . . . . . . . . . . . . 11 4.3. TCP UDP in SUNH . . . . . . . . . . . . . . . . . . . . . 11 4.4. Minimum packet length . . . . . . . . . . . . . . . . . . 12 4.4.1. SUNH header and SUNH payload is greater than forty-six bytes . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4.2. The SUNH payload has self-describing length . . . . . 13 4.4.3. Explicit padding . . . . . . . . . . . . . . . . . . 13 4.5. Receiver processing . . . . . . . . . . . . . . . . . . . 14 5. Router requirements . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Herbert Expires 20 July 2026 [Page 2] Internet-Draft SUNH January 2026 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 exhibit a majority of small packets, like for KVcache in AI, where packet sizes may commonly be 256 bytes or less. For traditional network layer protocols, including IPv4 and IPv6, network headers represent 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 a table lookup. Long addresses require CAMs, TCAMs, or tree mechanisms that increase latency and power consumption in routers. 1.2. 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 as well as Network Layer fields. The fundamental problem with the AI Header Formats in the SUE approach is that it's not compatible with commodity 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 Herbert Expires 20 July 2026 [Page 3] Internet-Draft SUNH January 2026 of bits in the forty-eight bits of the Destination address are valid so the normal CAM lookup will fail. The work around would be to place the NIC in Promiscuous mode and then match the XPU Destination address in software. 1.3. Introducing Scale-Up Network Header This document specifies the Scale-Up Network Header, or SUNH, that is a concise and efficient network layer protocol header. SUNH defines a common four byte SUNH header prefix that is followed by a source and destination address of some size. It's a "scale-up protocol" since an intended use case is in scale-up networks for AI, however the protocol is generic and may have broad use cases in datacenter networks. The SUNH network header provides four primary benefits: * It reduces the amount of on-the-wire protocol overhead * It simplifies route lookup to be more efficient with lower latency * It retains the properties and benefits of a Network Layer header including compatibility with deployed Ethernet switches * It obviates the need to use a UDP shim header before the encapsulated transport protocol. An encapsulated transport protocol could be directly encapsulated in SUNH using it's own protocol number and the UDP header is not needed for compatibility with switches. 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 as only the Ethernet addresses are considered when switching and they're not modified by SUNH. 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 header, perform route lookups on the SUNH destination address, and then forward the packet. The SUNH header includes Hop Limit, Traffic Class, and Flow Label fields that can be used with the same semantics as for routing IP packets. We can compare the header overhead of SUNH to IPv4 and IPv6, and can compare SUNH to cases where a shim UDP header is used: Herbert Expires 20 July 2026 [Page 4] Internet-Draft SUNH January 2026 +--------------------------------+------------+ | Protocol header | # bytes | +================================+============+ | SUNH with 8-bit addresses | 6 bytes | +--------------------------------+------------+ | SUNH with 16-bit bit addresses | 8 bytes | +--------------------------------+------------+ | SUNH with 24-bit bit addresses | 10 bytes | +--------------------------------+------------+ | SUNH with 32-bit bit addresses | 12 bytes | +--------------------------------+------------+ | IPV4 | 20 bytes | +--------------------------------+------------+ | IPV4 + UDP header | 28 bytes | +--------------------------------+------------+ | IPV6 | 40 bytes | +--------------------------------+------------+ | IPV6 + UDP header | 48 bytes | +--------------------------------+------------+ 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 A SUNH header is comprised of a four byte common prefix followed by a source and destination address. The common prefix contains a Next Protocol number, Hop Limit, Traffic Class, and Flow Label. The source and destination addresses can have sizes of eight, sixteen, twenty-four, or thirty-two bits (one, two, three, or four bytes). The addresses may be omitted to create an "address-less" network header. ENdpoint addresses would be inferred from Layer 2 addresses (e.g. Ethernet addresses). 2.1. SUNH domains SUNH only works within a limited domain called a "SUNH domain". THe addresses of SUNH are effectively private addresses that are not routable on the Internet. Herbert Expires 20 July 2026 [Page 5] Internet-Draft SUNH January 2026 2.2. SUNH EtherType SUNH is distinguished by its own EtherType when encapsulated in Ethernet. Different EtherTypes may indicate the size of the SUNH addresses in packets, or one size may be configured in the SUNH domain. For other Layer 2 technologies, an equivalent identifier may indicate SUNH is encapsulated. Using an EtherType specific to SUNH facilitated filtering of SUNH at boundaries of a limited domain. 2.3. Interpretation of a SUNH header Within a limited domain a SUNH header may be interpreted as a the header for a standalone network layer protocol, or as a compressed IPv4 or IPv6 header. Note that any interpretation of SUNH is local to the SUNH domain. There are no fields in the SUNH header that indicate which interpretation is applicable in the domain. It is expected that all the nodes in the domain are configured with the same interpretation. 2.3.1. SUNH as a standalone network layer header SUNH header may be interpreted as its own network layer protocol in a limited domain. Effectively, SUNH would be a variant of IP with addresses of some length. Host stacks could be adapted to support SUNH as another network layer protocol. 2.3.2. SUNH as a compressed IP header The SUNH header may be interpreted as a compressed IPv4 or IPv6 header. In this case, a "SUNH prefix" is specified for a domain. The prefix serves as the implied network prefix for SUNH addresses. A SUNH address is thus the host part (i.e. low order bits) of a fully qualified IPv4 or IPv6 address. THe SUNH prefix is either for IPv4 or IPv6. A SUNH address can be expanded to an fully qualified IPv4 or IPv6 address by prepending the SUNH prefix to the SUNH address. A SUNH header can be expanded to an IPv4 or IPv6 header by expanding the SUNH addresses and copying the common fields from the SUNH header to the IPv4 or IPv6 header. All participating hosts in a SUNH domain are configured with the common SUNH prefix and whether SUNH headers sent in the domain are compressed IPv4 or IPv6 headers. 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. Herbert Expires 20 July 2026 [Page 6] Internet-Draft SUNH January 2026 2.4. 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 SUNH Destination Address, and there are no multicast or broadcast addresses. This specification allows four sizes of SUNH addresses. This allows use an address size that scales well for the domain. For instance, there were at most 1000 nodes in some network then 16-bit SUNH addresses could be used and the nodes could be assigned addresses in in the range 0 to 1023. 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. The size of SUNH addresses in a packet can either be inferred from the EtherTYpe or from configuration in the SUNH domain. In the case of using EtherTypes, different EtherType would be defined for different size SUNH addresses. In the case of configuration, all the nodes in the SUNH would assume that size of SUNH addresses in the domain is the configured value. 2.5. 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 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]. 3.1. Common prefix The common SUNH prefix is shown below: Herbert Expires 20 July 2026 [Page 7] Internet-Draft SUNH January 2026 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. SUNH defines its own number space that is distinct from IP Protocol numbers [IANA-PN], however there may be some overlap for convenience. 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 adn the handling is slightly differ. 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. A node that is the destination of a packet MUST NOT discard a packet with Hop Limit equal to zero. Flow Label 12-bit flow label. This is smaller version of the IPv6 Flow Label and is otherwise set and processed with the same semantics Note that the SUNH header does not have a Total Length field or Payload Length field as IPv4 and IPv6 has. 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. Since the SUNH header does not have a length, care must be taken to ensure that the real length of a packet can be unambiguously interpreted especially with regards to meeting the minimum Ethernet packet size requirement (see Section 4.4). 3.2. SUNH with 8-bit addresses The format of the SUNH header with 8-bit address is show below Herbert Expires 20 July 2026 [Page 8] Internet-Draft SUNH January 2026 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Src Address | Dest Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addresses: Source Address 8-bit SUNH address of the originator of the packet. This maybe the host part of a fully qualified IPv4 (24-bit prefix) or IPv6 address (120-bit prefix). Destination Address 8-bit SUNH address of the intended recipient. This may be the host part of a fully qualified IPv4 (24-bit prefix) or IPv6 address (120-bit prefix). 3.3. SUNH with 16-bit addresses The format of the SUNH header with 16-bit addresses is show below 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addresses: Source Address 16-bit SUNH address of the originator of the packet. This may be the host part of a fully qualified IPv4 (16-bit prefix) or IPv6 address (112-bit prefix). Destination Address 16-bit SUNH address of the intended recipient. This maybe the host part of a fully qualified IPv4 (16-bit prefix) or IPv6 address (112-bit prefix). 3.4. SUNH with 24-bit addresses The format of the SUNH header with 24-bit addresses is show below Herbert Expires 20 July 2026 [Page 9] Internet-Draft SUNH January 2026 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 | Dest Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address cont | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addresses: Source Address 24-bit SUNH address of the originator of the packet. This may be the host part of a fully qualified IPv4 (8-bit prefix) or IPv6 address (104-bit prefix). Destination Address 24-bit SUNH address of the intended recipient (note that the Destination Address is split over two rows in the diagram). This may be the host part of a fully qualified IPv4 (16-bit prefix) or IPv6 address (104-bit prefix). 3.5. SUNH with 32-bit addresses The format of the SUNH header with 32-bit addresses is show below 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Addresses: Source Address 32-bit SUNH address of the originator of the packet. This may be a fully qualified IPv4 address or the host part of an IPv6 address (96-bit prefix). Destination Address 32-bit SUNH address of the intended recipient of the packet. This may be a fully qualified IPv4 address or the host part of an IPv6 address (96-bit prefix). Herbert Expires 20 July 2026 [Page 10] Internet-Draft SUNH January 2026 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 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). 4.3. TCP 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 with 8-bit addresses is: 0 7 8 15 16 23 24 31 +----------+----------+----------+----------+ | Src addr | Dst addr | zero | protocol | +----------+----------+----------+----------+ | TCP/UDP length | +----------+----------+ The pseudo header with 16-bit addresses is: Herbert Expires 20 July 2026 [Page 11] Internet-Draft SUNH January 2026 0 7 8 15 16 23 24 31 +----------+----------+----------+----------+ | source address | destination address | +----------+----------+----------+----------+ | zero | protocol | TCP/UDP length | +----------+----------+----------+----------+ The pseudo header with 24-bit addresses is: 0 7 8 15 16 23 24 31 +----------+----------+----------+----------+ | source address | dest | +----------+----------+----------+----------+ | dst address cont | zero | protocol | +----------+----------+----------+----------+ | TCP/UDP length | +----------+----------+ The pseudo header with 32-bit addresses is: 0 7 8 15 16 23 24 31 +----------+----------+----------+----------+ | source address | +----------+----------+----------+----------+ | destination address | +----------+----------+----------+----------+ | zero | protocol | TCP/UDP 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. 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 and the real length of a packet can be unambiguously determined. There are three ways to ensure Ethernet frames have a proper minimum length. These are described below. Herbert Expires 20 July 2026 [Page 12] Internet-Draft SUNH January 2026 4.4.1. SUNH header and SUNH payload is greater than forty-six bytes If the length of the SUNH header including addresses plus the length of SUNH payload is greater than or equal to forty-six 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 header plus the payload length is greater than or equal to forty-six bytes. 4.4.2. The SUNH payload has self-describing length If the SUNH payload has self-describing length then the minimum length requirement is satisfied by padding the packet with zeroes up to be at least sixty-four bytes in size. 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 SUNW payload. For instance, if a UDP packet with minimum length of eight is encapsulated in a SUNH header with sixteen bit addresses then the total length of the Ethernet payload is sixteen bytes and the packet is sent by padding it with thirty bytes (zeroes after the UDP header). 4.4.3. Explicit padding If the SUNH header plus payload is less than forty-six bytes length the payload length cannot be deduced from the protocol headers in the SUNH payload, then explicit padding can be used. The idea is to insert a "SUNH Padding Header" after the SUNH header. The format of the padding header is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ zeroes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Next Header The same semantics as Next Header in the SUNH header (see Section 3.1). Herbert Expires 20 July 2026 [Page 13] Internet-Draft SUNH January 2026 Length Length of the padding. This includes two bytes for the Next Header and Length and the number of following zeroes. 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 with sixteen bit addresses 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 using the SUNH Padding Header with Length of eighteen. For our example, the SUNH Padding Header would be: 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 | 18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ 16 bytes of zeroes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The next protocol field in the SUNH would be set to 252 to indicate the Padding Header follows the SUNH header. The Next Header field in the Padding Header is set to 6 to indicate TCP. 4.5. 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 into 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 Herbert Expires 20 July 2026 [Page 14] Internet-Draft SUNH January 2026 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 standalone network protocol 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 is specific to each SUNH domain. 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 the router is performing ECMP routing 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 forward the packet then the non-zero hop limit is decremented. 6. IANA Considerations IANA is requested to create a new registry named "Assigned SUNH Protocol Numbers". These are 8-bit numbers. The initial assignments are listed below: Herbert Expires 20 July 2026 [Page 15] Internet-Draft SUNH January 2026 +---------+----------+-----------------+---------------+ | Decimal | Keyword | Protocol | Reference | +---------+----------+-----------------+---------------+ | 6 | TCP | Transmission | RFC9293 | | | | control | | +---------+----------+-----------------+---------------+ | 17 | UDP | User | RFC768 | | | | datagram | | +---------+----------+-----------------+---------------+ | 196-250 | | User defined | [This | | | | | document] | +---------+----------+-----------------+---------------+ | 252 | SUNHPAD | SUNH padding | [This | | | | and testing | document] | +---------+----------+-----------------+---------------+ | 253 | | Experimentation | RFC3692 | | | | and testing | | +---------+----------+-----------------+---------------+ | 254 | | Experimentation | RFC3692 | | | | and testing | | +---------+----------+-----------------+---------------+ | 255 | Reserved | | RFC3692 | | | | | | +---------+----------+-----------------+---------------+ 7. Security Considerations SUNH is a new network protocol explicitly designed for use in limited domains. Border routers of limited domains can discard packets with SUMH headers based on their EtherType. Within the limited domain it is expected that nodes are trusted. Otherwise, SUNH does not introduce any new security concerns. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References Herbert Expires 20 July 2026 [Page 16] Internet-Draft SUNH January 2026 [IANA-PN] "Assigned Internet Protocol Numbers", . [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, . [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, . [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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [SUE] "Scale-Up Ethernet Framework", September 2025, . Author's Address Tom Herbert XDPnet Los Gatos, CA, United States of America Email: tom@herbertland.com Herbert Expires 20 July 2026 [Page 17]