Summary

  • In an IPv6 jumbogram, a zero Payload Length in the base header directs a receiver to a Jumbo Payload option in the immediately following Hop-by-Hop Options header.
  • The option carries the actual payload length in 32 bits and is valid only above 65,535 octets; zero alone proves neither emptiness nor validity.
  • Correct syntax still does not prove that every device on the path can carry the packet, or that a missing ICMP error establishes successful delivery.

A small field that hands off authority

The ordinary IPv6 base header has a 16-bit Payload Length field. It counts everything after the fixed 40-octet header, including extension headers. That works until the payload is larger than 65,535 octets. RFC 2675 does not reinterpret the maximum value or add bytes to the base header. It uses zero as a sentinel and moves the authoritative length into a Jumbo Payload option.

That handoff is conditional. A node that receives a base Payload Length of zero, sees a Hop-by-Hop Options header as the next header and still has octets after the IPv6 header must process that options header. A Jumbo Payload option there carries an unsigned 32-bit Jumbo Payload Length. The value covers the extension headers and upper-layer data after the IPv6 base header, and it must exceed 65,535.

This is why a packet listing that stops at “Payload Length: 0” has stopped one field too early. It has reported the trigger but not the value to which the trigger delegates. A defensible finding needs the next-header value, the presence and placement of the option, its declared length and the number of captured bytes. If a capture was truncated, the analyst must distinguish an incomplete observation from a malformed packet.

The pair is the receipt

The standard defines the invalid combinations with unusual clarity. Zero followed by a Hop-by-Hop Options header but no Jumbo Payload option is an error. A non-zero base Payload Length combined with the Jumbo option is an error. A Jumbo Payload Length below 65,536 is an error. A packet carrying both a Jumbo Payload option and a Fragment header is also an error. RFC 2675 assigns ICMP Parameter Problem responses with pointers aimed at the field or option that created the contradiction.

Those rules make the evidence relational. Neither value is trustworthy in isolation. The zero in the base header and the large value in the option form a paired statement; the surrounding header chain determines whether the pair is coherent. A decoder that labels zero as “empty” loses valid traffic. One that accepts any zero as a jumbogram admits malformed traffic. The safer record preserves both the base field and the option, plus the validation outcome.

RFC 4443 adds a boundary to error evidence. A Parameter Problem message is Type 4, and Code 0 means an erroneous header field was encountered. The offending packet is discarded, and an ICMPv6 response should be sent subject to the protocol’s rules. Yet the absence of that response is not proof that the packet was accepted. Filters, rate limits, asymmetric routing or a missing return path can all erase the visible signal.

A second zero, governed separately

UDP introduces another apparent zero. For a UDP datagram carried in an IPv6 jumbogram, RFC 2675 permits the UDP Length field to be zero when the actual UDP length exceeds 65,535. The receiver derives that length from the Jumbo Payload Length after subtracting the length of intervening extension headers. The checksum calculation uses the real derived length, not zero.

The two zeroes therefore have coordinated but separate meanings. The IPv6 zero points to the Jumbo Payload option; the UDP zero invokes the UDP-specific jumbogram rule. Observing one does not license an analyst to infer the other. TCP has no equivalent packet-length field. In this context its Maximum Segment Size value of 65,535 is treated as unbounded, while the useful segment size is constrained by Path MTU Discovery and the actual path.

Valid on paper, dependent on the path

Jumbograms matter only on links whose MTU is greater than 65,575 octets: the 40-octet IPv6 header plus a payload beyond 65,535. Implementations that do not attach to such links are not required to support them. RFC 8201 further makes path capacity a discovered property: the Path MTU is the minimum link MTU along the route, and an oversized packet can be dropped with an ICMPv6 Packet Too Big message.

The Jumbo option can therefore establish syntactic validity without establishing delivery. A sender, receiver and first link may support the format while a tunnel, middlebox or later link does not. Conversely, a policy that rejects every packet merely because it contains the Jumbo option rejects a format that the IPv6 standards recognize as valid. RFC 9288 makes that distinction explicit when discussing overly broad extension-header filtering.

Operational evidence should keep three claims separate: what the packet declared, whether the header chain satisfied the standard, and what the path did with it. The first comes from fields. The second comes from parsing and consistency checks. The third requires path observations—successful reception, counters, Packet Too Big messages, controlled probes or corroborating traces. Collapsing the three turns an economical sentinel into a false verdict.

Sources