< draft-ietf-ipngwg-jumbograms-00.txt   draft-ietf-ipngwg-jumbograms-01.txt >
INTERNET-DRAFT D. Borman, Berkeley Software Design INTERNET-DRAFT D. Borman, Berkeley Software Design
February 26, 1999 S. Deering, Cisco June 25, 1999 S. Deering, Cisco
Obsoletes: RFC2147 R. Hinden, Nokia Obsoletes: RFC2147 R. Hinden, Nokia
IPv6 Jumbograms IPv6 Jumbograms
<draft-ietf-ipngwg-jumbograms-00.txt> <draft-ietf-ipngwg-jumbograms-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [STD-PROC]. all provisions of Section 10 of RFC 2026 [STD-PROC].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 31
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet Draft will expire on August 26, 1999. This Internet Draft will expire on December 25, 1999.
Abstract Abstract
A "jumbogram" is an IPv6 packet containing a payload longer than A "jumbogram" is an IPv6 packet containing a payload longer than
65,535 octets. This document describes the IPv6 Jumbo Payload 65,535 octets. This document describes the IPv6 Jumbo Payload
option, which provides the means of specifying such large payload option, which provides the means of specifying such large payload
lengths. It also describes the changes needed to TCP and UDP to make lengths. It also describes the changes needed to TCP and UDP to make
use of jumbograms. use of jumbograms.
Jumbograms are relevant only to IPv6 nodes that may be attached to Jumbograms are relevant only to IPv6 nodes that may be attached to
skipping to change at page 2, line 47 skipping to change at page 2, line 47
link that do not support the Jumbo Payload option and it can not be 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 guaranteed that the Jumbo Payload option will not be sent to those
nodes. nodes.
The UDP header [UDP] has a 16-bit Length field which prevents it from 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 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 have a Length field, both the TCP MSS option and the TCP Urgent field
are constrained to 16 bits. This document specifies some simple are constrained to 16 bits. This document specifies some simple
enhancements to TCP and UDP to enable them to make use of jumbograms. 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 An implementation of TCP or UDP on an IPv6 node that supports the
Jumbo Payload option MUST include the enhancements specified here. 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 1.1 Document History
This document merges and updates material that was previously This document merges and updates material that was previously
published in two separate documents: published in two separate documents:
- The specification of the Jumbo Payload option previously - The specification of the Jumbo Payload option previously
appeared as part of the IPv6 specification in RFC 1883. RFC appeared as part of the IPv6 specification in RFC 1883. RFC
1883 has been superseded by RFC 2460, which no longer includes 1883 has been superseded by RFC 2460, which no longer includes
specification of the Jumbo Payload option. specification of the Jumbo Payload option.
- The specification of TCP and UDP enhancements to support - The specification of TCP and UDP enhancements to support
jumbograms previously appeared as RFC 2147. RFC 2147 is jumbograms previously appeared as RFC 2147. RFC 2147 is
obsoleted by this document. obsoleted by this document.
1.2 Requirements 1.2 Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords must, must not, required, shall, shall not, should,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, if and where they appear should not, recommended, may, and optional, if and where they appear
in this document, are to be interpreted as described in [KEYWORDS]. in this document, are to be interpreted as described in [KEYWORDS].
2. Format of the Jumbo Payload Option 2. Format of the Jumbo Payload Option
The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options
header, immediately following the IPv6 header. This option has an header, immediately following the IPv6 header. This option has an
alignment requirement of 4n + 2. (See [IPv6, Section 4.2] for alignment requirement of 4n + 2. (See [IPv6, Section 4.2] for
discussion of option alignment.) The option has the following discussion of option alignment.) The option has the following
format: format:
skipping to change at page 8, line 19 skipping to change at page 8, line 19
4719 Weston Hills Drive 4719 Weston Hills Drive
Eagan, MN 55123 Eagan, MN 55123
USA USA
Stephen E. Deering phone: +1 408 527 8213 Stephen E. Deering phone: +1 408 527 8213
Cisco Systems, Inc. email: deering@cisco.com Cisco Systems, Inc. email: deering@cisco.com
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Robert M. Hinden phone: +1 408 990 2004 Robert M. Hinden phone: +1 650 625 2004
Nokia email: hinden@iprg.nokia.com Nokia email: hinden@iprg.nokia.com
232 Java Drive 313 Fairchild Drive
Sunnyvale, CA 94089 Mountain View, CA 94043
USA USA
8. References 8. References
[ICMPv6] Conta, A., S. Deering, ICMP for the Internet Protocol [ICMPv6] Conta, A., S. Deering, ICMP for the Internet Protocol
Version 6 (IPv6), RFC 2463, December 1998. Version 6 (IPv6), RFC 2463, December 1998.
[IPv6] Deering, S., R. Hinden, Internet Protocol Version 6 (IPv6) [IPv6] Deering, S., R. Hinden, Internet Protocol Version 6 (IPv6)
Specification, RFC 2460, December 1998. Specification, RFC 2460, December 1998.
skipping to change at line 354 skipping to change at page 9, line 4
[STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3, [STD-PROC] Bradner, S., The Internet Standards Process -- Revision 3,
RFC 2026, October 1996. RFC 2026, October 1996.
[TCP] Postel, J., Transmission Control Protocol, RFC 793, [TCP] Postel, J., Transmission Control Protocol, RFC 793,
September 1981. September 1981.
[TCP-EXT] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for [TCP-EXT] Jacobson, V., R. Braden, D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[UDP] Postel, J., User Datagram Protocol, RFC 768, August 1980. [UDP] Postel, J., User Datagram Protocol, RFC 768, August 1980.
9. Changes from previous version of this draft
Version 01
- Added note to introduction about reliability of 16 bit TCP/UDP
checksum w/ jumbograms.
- Made case of "must"'s consistent.
 End of changes. 9 change blocks. 
10 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/