RFC 2147

RFC 2147: TCP and UDP over IPv6 Jumbograms 🦋

Okay bestie, here's the paperwork vibe check 📋✨ This is RFC 2147, titled "TCP and UDP over IPv6 Jumbograms", from the Network Working Group. It was written by David A. Borman at Berkeley Software Design, Inc. and dated May 1997. It's a Standards Track document, and it Updates RFC 1883 (the IPv6 spec) 💜. It doesn't obsolete anything.

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 bigger than 65535 bytes, which people call jumbograms 🐘. That works through the Jumbo Payload hop-by-hop option [Deering95]. UDP has a 16-bit length field, so it literally can't use jumbograms 😭. TCP doesn't have a length field, but its MSS option and Urgent field are both limited to 16 bits, so it's stuck too. This document lists some simple changes that let TCP and UDP use IPv6 jumbograms 🎀.

2. UDP Jumbograms 💖

Okay so UDP needs to either extend its length field or ignore it. The field can't get any bigger, so a length of zero means "ignore me" 🙈. The true length then comes from the length in the "pseudo-header" instead. This works because the UDP length field includes the UDP header, so the smallest valid value is 8 🌸.

When sending a UDP packet, if and only if 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 carrying a UDP packet longer 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 holds the length of the IP packet excluding the IPv6 header. That means it covers all extension headers present, plus the UDP header, plus the UDP data 🧚. The length field in the IPv6 header is zero to signal that the Jumbo Payload option is there 🔥.

If a UDP packet arrives with a length field of zero, its length gets computed from the length field in the Jumbo Payload option, minus the length of all extension headers between the IPv6 header and the UDP header 👑.

3. TCP Jumbograms 🍓

TCP has no length field, so nothing limits how long one TCP packet can be 🙌. The catch is that the MSS value negotiated at the start of the connection caps the biggest TCP packet you can send, and the Urgent Pointer can't point past 65535 bytes 💀.

3.1 TCP MSS

When picking the MSS value to send, if the MTU of the directly attached interface is greater than 65535, set the MSS value to 65535 ✨.

When an MSS value of 65535 is received, it gets treated as infinity ♾️. MTU discovery code, starting from the MTU of the outgoing interface, will be used to figure out the actual MSS 🔍.

3.2 TCP Urgent Pointer

Honestly the Urgent Pointer problem could be fixed by adding a TCP Urgent Pointer Option 🤓. But applications using jumbograms probably won't use Urgent Pointers, so a less intrusive change similar to the MSS one will do the job 💜.

When a TCP packet is sent with an Urgent Pointer (meaning the URG bit is 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 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 normal TCP processing 🌸.

Otherwise, the TCP packet has to be split into two pieces 🔪. The first piece has the data up to, but not including, the data the Urgent Pointer points to. Its Urgent field is set to 65535 to show that the Urgent Pointer is past the end of this packet. The second piece can then be sent with the Urgent field set normally 🎀.

Note: The first piece doesn't have to include all of the data up to the Urgent Pointer. It can be shorter, as long as it ends within 65534 bytes of the Urgent Pointer, so the offset to the Urgent Pointer in the second piece is less than 65535 bytes 🍭.

For TCP input processing: when a TCP packet arrives 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, not the offset in the Urgent field 🧠.

It's also worth noting that even though the TCP window is only 16 bits, bigger windows are possible through the TCP Window Scale option [Jacobson92] 🪟✨.

4. Security Considerations 🔐

There are no known security issues involved in these changes. Iconic, no notes 💅🫶.

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