IPv6 Jumbograms
RFC 2675
| Document | Type |
RFC - Proposed Standard
(August 1999; Errata)
Obsoletes RFC 2147
|
|
|---|---|---|---|
| Authors | David Borman , Steve Deering , Bob Hinden | ||
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2675 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group D. Borman
Request for Comments: 2675 Berkeley Software Design
Obsoletes: 2147 S. Deering
Category: Standards Track Cisco
R. Hinden
Nokia
August 1999
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.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
A "jumbogram" is an IPv6 packet containing a payload longer than
65,535 octets. This document describes the IPv6 Jumbo Payload
option, which provides the means of specifying such large payload
lengths. It also describes the changes needed to TCP and UDP to make
use of jumbograms.
Jumbograms are relevant only to IPv6 nodes that may be attached to
links with a link MTU greater than 65,575 octets, and need not be
implemented or understood by IPv6 nodes that do not support
attachment to links with such large MTUs.
1. Introduction
jumbo (jum'bO),
n., pl. -bos, adj.
-n.
1. a person, animal, or thing very large of its kind.
-adj.
2. very large: the jumbo box of cereal.
[1800-10; orig. uncert.; popularized as the name of a large
elephant purchased and exhibited by P.T. Barnum in 1882]
-- www.infoplease.com
Borman, et al. Standards Track [Page 1]
RFC 2675 IPv6 Jumbograms August 1999
The IPv6 header [IPv6] has a 16-bit Payload Length field and,
therefore, supports payloads up to 65,535 octets long. This document
specifies an IPv6 hop-by-hop option, called the Jumbo Payload option,
that carries a 32-bit length field in order to allow transmission of
IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in
length. Packets with such long payloads are referred to as
"jumbograms".
The Jumbo Payload option is relevant only for IPv6 nodes that may be
attached to links with a link MTU greater than 65,575 octets (that
is, 65,535 + 40, where 40 octets is the size of the IPv6 header).
The Jumbo Payload option need not be implemented or understood by
IPv6 nodes that do not support attachment to links with MTU greater
than 65,575.
On links with configurable MTUs, the MTU must not be configured to a
value greater than 65,575 octets if there are nodes attached to that
link that do not support the Jumbo Payload option and it can not be
guaranteed that the Jumbo Payload option will not be sent to those
nodes.
The UDP header [UDP] has a 16-bit Length field which prevents it from
making use of jumbograms, and though the TCP header [TCP] does not
have a Length field, both the TCP MSS option and the TCP Urgent field
are constrained to 16 bits. This document specifies some simple
enhancements to TCP and UDP to enable them to make use of jumbograms.
An implementation of TCP or UDP on an IPv6 node that supports the
Jumbo Payload option must include the enhancements specified here.
Note: The 16 bit checksum used by UDP and TCP becomes less accurate
as the length of the data being checksummed is increased.
Application designers may want to take this into consideration.
1.1 Document History
This document merges and updates material that was previously
published in two separate documents:
- The specification of the Jumbo Payload option previously appeared
as part of the IPv6 specification in RFC 1883. RFC 1883 has been
superseded by RFC 2460, which no longer includes specification of
the Jumbo Payload option.
- The specification of TCP and UDP enhancements to support
jumbograms previously appeared as RFC 2147. RFC 2147 is obsoleted
by this document.
Borman, et al. Standards Track [Page 2]
RFC 2675 IPv6 Jumbograms August 1999
2. Format of the Jumbo Payload Option
The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options
header, immediately following the IPv6 header. This option has an
alignment requirement of 4n + 2. (See [IPv6, Section 4.2] for
discussion of option alignment.) The option has the following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Show full document text