TCP and UDP over IPv6 Jumbograms
RFC 2147

Document Type RFC - Proposed Standard (May 1997; No errata)
Obsoleted by RFC 2675
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2147 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
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].

Borman                      Standards Track                     [Page 1]
RFC 2147            TCP and UDP over IPv6 Jumbograms            May 1997

      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

Borman                      Standards Track                     [Page 2]
RFC 2147            TCP and UDP over IPv6 Jumbograms            May 1997
Show full document text