Network Working Group Internet Engineering Task Force Internet-Draft IPNG Working Group Updates: 1883 David Borman Berkeley Software Design, Inc. August 1996 TCP and UDP over IPv6 Jumbograms <draft-borman-jumbograms-00.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Overview IPv6 supports datagrams larger than 65535 bytes long, called jumbograms. The UDP protocol has a 16 length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, it does have an MSS option that has a 65535 byte length limitation. This document describes some simple changes that can be made to TCP and UDP over IPv6 to allow them to take advantage of jumbograms. 2. UDP Jumbograms Because the UDP length field includes the UDP header, the minimum valid value for this field is 8. To send a UDP packet with a UDP length > 65535, set the UDP length field to zero, and the IPv6 length field to correctly reflect the length of the UDP packet. If a UDP packet arrives with a length field of zero, the UDP IPNG Working Group Expires February 1997 [Page 1]
^L Internet-Draft TCP and UDP over IPv6 Jumbograms August 1996 length should be ignored, and the length field from the pseudo header should be used. 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. 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, should be used to determine the actual MSS. 4. Security Considerations There are no known security issues involved in these changes. Author's Address David A. Borman Berkeley Software Design, Inc. 4719 Weston Hills Drive Eagan, MN 55123 Phone: (612) 405-8194 Mailing List: ipng@sunroof.Eng.Sun.COM Email: dab@bsdi.com IPNG Working Group Expires February 1997 [Page 2]
