RFC 2147: TCP and UDP over IPv6 Jumbograms
This RFC has been replaced. Do not implement against it for new work — it was formally obsoleted by RFC 2675.
Current version: RFC 2675 — IPv6 Jumbograms
In plain English — editorial summary, not part of the RFC
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]
Document record
- Document ID
- RFC2147
- Published
- May 1997
- Authors
- D. Borman
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- int
- Pages
- 3
- Also known as
- —
- Obsoleted by:
- RFC 2675
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 3096Requirements for robust IP/UDP/RTP header compressionCurrent
July 2001
- RFC 3243RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP CompressionCurrent
April 2002
- RFC 2393IP Payload Compression Protocol (IPComp)Obsoleted
December 1998
- RFC 2394IP Payload Compression Using DEFLATECurrent
December 1998
- RFC 2395IP Payload Compression Using LZSCurrent
December 1998
- RFC 2354Options for Repair of Streaming MediaCurrent
June 1998
- RFC 3759RObust Header Compression (ROHC): Terminology and Channel Mapping ExamplesCurrent
April 2004
- RFC 6145IP/ICMP Translation AlgorithmObsoleted
April 2011
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?