Browse Prior Art Database

TCP and UDP over IPv6 Jumbograms (RFC2147)

IP.com Disclosure Number: IPCOM000002703D
Original Publication Date: 1997-May-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 3 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Borman: AUTHOR

Related Documents

10.17487/RFC2147: DOI

Abstract

IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. 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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

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 t...

Processing...
Loading...