TCP and UDP over IPv6 Jumbograms
Adapting TCP and UDP to handle IPv6 jumbograms larger than 65535 bytes.
Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, DOI 10.17487/RFC2147, May 1997, <https://www.rfc-editor.org/info/rfc2147>.
@misc{rfc2147,
series = {Request for Comments},
number = 2147,
howpublished = {RFC 2147},
publisher = {RFC Editor},
doi = {10.17487/RFC2147},
url = {https://www.rfc-editor.org/info/rfc2147},
author = {D. Borman},
title = {{TCP and UDP over IPv6 Jumbograms}},
pagetotal = 3,
year = 1997,
month = may,
} RFC text
Contents
Network Working Group D. Borman
Request for Comments: 2147 Berkeley Software Design, Inc.
Updates: 1883 May 1997
Category: Standards Track
TCP and UDP over IPv6 Jumbograms
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. Overview
IPv6 supports datagrams larger than 65535 bytes long, often referred
to as jumbograms, through use of the Jumbo Payload hop-by-hop option
[Deering95]. The UDP protocol has a 16-bit length field that keeps
it from being able to make use of jumbograms, and though TCP does not
have a length field, both the MSS option and the Urgent field are
constrained by 16-bits. This document describes some simple changes
that can be made to allow TCP and UDP to make use of IPv6 jumbograms.
2. UDP Jumbograms
To allow UDP to make use of jumbograms, either the UDP length field
needs to be extended, or it needs to be ignored. Since the size of
the field can't be changed, a length of zero is used to indicate that
it is to be ignored, and the length in the "pseudo-header" is to be
used to determine the true length of the UDP header plus data. This
works because UDP length field includes the UDP header, so the
minimum valid value for this field is 8.
When sending a UDP packet, if and only if the length of the UDP
header plus data is greater than 65,535, set the length field in the
UDP header to zero.
Note 1: The length used in the "pseudo-header" for computing the
UDP checksum is always the true length of the UDP header plus
data, NOT zero [RFC-1883, Section 8.1].
Note 2: An IPv6 packet that carries a UDP packet of length
greater than 65,535 will necessarily carry a Jumbo Payload option
in a Hop-by-Hop Options header [RFC1883, Section 4.3]). The
length field in the Jumbo Payload option contains the length of
the IP packet excluding the IPv6 header, that is, it contains the
length of all extension headers present plus the UDP header plus
the UDP data. The length field in the IPv6 header contains zero
to indicate the presence of the Jumbo Payload option.
If a UDP packet is received with a length field of zero, the length
of the UDP packet is computed from the length field in the Jumbo
Payload option minus the length of all extension headers present
between the IPv6 header and the UDP header.
3. TCP Jumbograms
Because there is no length field in the TCP header, there is nothing
limiting the length of an individual TCP packet. However, the MSS
value that is negotiated at the beginning of the connection limits
the largest TCP packet that can be sent, and the Urgent Pointer
cannot reference data beyond 65535 bytes.
3.1 TCP MSS
When determining what MSS value to send, if the MTU of the directly
attached interface is greater than 65535, then set the MSS value to
65535.
When an MSS value of 65535 is received, it is to be treated as
infinity. MTU discovery code, starting with the MTU of the outgoing
interface, will be used to determine the actual MSS.
3.2 TCP Urgent Pointer
The Urgent Pointer problem could be fixed by adding a TCP Urgent
Pointer Option. However, since it is unlikely that applications
using jumbograms will also use Urgent Pointers, a less intrusive
change similar to the MSS change will suffice.
When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG
bit set), first calculate the offset from the Sequence Number to the
Urgent Pointer. If the offset is less than 65535, fill in the Urgent
field and continue with the normal TCP processing. If the offset is
greater than 65535, and the offset is greater than or equal to the
length of the TCP data, fill in the Urgent Pointer with 65535 and
continue with the normal TCP processing. Otherwise, the TCP packet
must be split into two pieces. The first piece contains data up to,
but not including the data pointed to by the Urgent Pointer, and the
Urgent field is set to 65535 to indicate that the Urgent Pointer is
beyond the end of this packet. The second piece can then be sent
with the Urgent field set normally.
Note: The first piece does not have to include all of the data up
to the Urgent Pointer. It can be shorter, just as long as it ends
within 65534 bytes of the Urgent Pointer, so that the offset to
the Urgent Pointer in the second piece will be less than 65535
bytes.
For TCP input processing, when a TCP packet is received with the URG
bit set and an Urgent field of 65535, the Urgent Pointer is
calculated using an offset equal to the length of the TCP data,
rather than the offset in the Urgent field.
It should also be noted that though the TCP window is only 16-bits,
larger windows can be used through use of the TCP Window Scale option
[Jacobson92].
4. Security Considerations
There are no known security issues involved in these changes.
5. References
[Jacobson92] Jacobson, V., R. Braden and D. Borman, "TCP Extensions
for High Performance", RFC 1323, LBL, ISI and Cray Research, May
1992.
[Deering95] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon Networks,
December 1995.
Author's Address
David A. Borman
Berkeley Software Design, Inc.
4719 Weston Hills Drive
Eagan, MN 55123
Phone: (612) 405-8194
Mailing List: ipng@sunroof.Eng.Sun.COM
Email: dab@bsdi.com
AI ELI5
On this page
§1IPv6 Jumbograms and Protocol Limits
IPv6 introduced the Jumbo Payload hop-by-hop option, which lets packets exceed the traditional 65535-byte limit. However, UDP and TCP were designed with 16-bit length and size fields that cap packets at 65535 bytes. UDP has an explicit 16-bit length field. TCP lacks a length field but uses a 16-bit Maximum Segment Size (MSS) option negotiated at connection start, and the Urgent Pointer field (16-bit offset) cannot reference data beyond byte 65535.
For high-performance networks and applications like video streaming or bulk transfer, this limits throughput. Simple changes allow both protocols to work with jumbograms while remaining backward-compatible.
IPv6 can carry huge packets, but UDP and TCP still think 65535 bytes is the limit. These are small changes to let them use bigger packets.
§2UDP and TCP MSS Adaptations
For UDP, when sending a jumbogram (length exceeds 65535 bytes), the sender sets the UDP length field to zero. The receiver reads the true length from the IPv6 Jumbo Payload option instead. Checksum computation always uses the true length, never zero. This works because UDP's minimum valid length is 8 (the header itself).
For TCP, the MSS negotiation is simple: when the attached interface MTU exceeds 65535, set the MSS to 65535. If an MSS of 65535 is received, treat it as infinity and use MTU discovery to find the actual limit. The TCP window remains 16-bit, but the TCP Window Scale option (RFC 1323) can enlarge windows separately for high-speed links.
For UDP, a zero length field means "look in the jumbo option for the real size." For TCP, an MSS of 65535 means "as big as MTU discovery can handle."
§3TCP Urgent Pointer Handling
The Urgent Pointer in TCP is a 16-bit offset that points to urgent data. If jumbogram data extends beyond byte 65535, the offset cannot fit. When the urgent-data offset exceeds 65535, the sender splits the packet into two pieces: the first contains data up to, but not including, the urgent data, with the Urgent field set to 65535 to signal that the pointer is beyond the packet. The second piece is then sent with the Urgent field set normally.
On the receiving side, when a TCP packet arrives with the URG bit set and Urgent field of 65535, the receiver treats the urgent offset as the length of the TCP data (byte 65535 + N in the next packet), not the value in the Urgent field.
If urgent data is further than 65535 bytes, TCP splits the packet in two: the first piece signals "urgent is further ahead," the second piece has the actual urgent data.