As per Relevance of the word contains, we have this rfc below:
Network Working Group D.
Request for Comments: 2147 Berkeley Software Design, Inc
Updates: 1883 May 1997
Category: Standards
TCP and UDP over IPv6
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
1.
IPv6 supports datagrams larger than 65535 bytes long, often
to as jumbograms, through use of the Jumbo Payload hop-by-hop
[Deering95]. The UDP protocol has a 16-bit length field that
it from being able to make use of jumbograms, and though TCP does
have a length field, both the MSS option and the Urgent field
constrained by 16-bits. This document describes some simple
that can be made to allow TCP and UDP to make use of IPv6 jumbograms
2. UDP
To allow UDP to make use of jumbograms, either the UDP length
needs to be extended, or it needs to be ignored. Since the size
the field can't be changed, a length of zero is used to indicate
it is to be ignored, and the length in the "pseudo-header" is to
used to determine the true length of the UDP header plus data.
works because UDP length field includes the UDP header, so
minimum valid value for this field is 8.
When sending a UDP packet, if and only if the length of the
header plus data is greater than 65,535, set the length field in
UDP header to zero
Note 1: The length used in the "pseudo-header" for computing
UDP checksum is always the true length of the UDP header
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
greater than 65,535 will necessarily carry a Jumbo Payload
in a Hop-by-Hop Options header [RFC1883, Section 4.3]).
length field in the Jumbo Payload option contains the length
the IP packet excluding the IPv6 header, that is, it contains
length of all extension headers present plus the UDP header
the UDP data. The length field in the IPv6 header contains
to indicate the presence of the Jumbo Payload option
If a UDP packet is received with a length field of zero, the
of the UDP packet is computed from the length field in the
Payload option minus the length of all extension headers
between the IPv6 header and the UDP header
3. TCP
Because there is no length field in the TCP header, there is
limiting the length of an individual TCP packet. However, the
value that is negotiated at the beginning of the connection
the largest TCP packet that can be sent, and the Urgent
cannot reference data beyond 65535 bytes
3.1 TCP
When determining what MSS value to send, if the MTU of the
attached interface is greater than 65535, then set the MSS value
65535.
When an MSS value of 65535 is received, it is to be treated
infinity. MTU discovery code, starting with the MTU of the
interface, will be used to determine the actual MSS
3.2 TCP Urgent
The Urgent Pointer problem could be fixed by adding a TCP
Pointer Option. However, since it is unlikely that
using jumbograms will also use Urgent Pointers, a less
change similar to the MSS change will suffice
When a TCP packet is to be sent with an Urgent Pointer (i.e., the
bit set), first calculate the offset from the Sequence Number to
Urgent Pointer. If the offset is less than 65535, fill in the
field and continue with the normal TCP processing. If the offset
greater than 65535, and the offset is greater than or equal to
length of the TCP data, fill in the Urgent Pointer with 65535
continue with the normal TCP processing. Otherwise, the TCP
must be split into two pieces. The first piece contains data up to
but not including the data pointed to by the Urgent Pointer, and
Borman Standards Track [Page 2]
RFC 2147 TCP and UDP over IPv6 Jumbograms May 1997
Urgent field is set to 65535 to indicate that the Urgent Pointer
beyond the end of this packet. The second piece can then be
with the Urgent field set normally
Note: The first piece does not have to include all of the data
to the Urgent Pointer. It can be shorter, just as long as it
within 65534 bytes of the Urgent Pointer, so that the offset
the Urgent Pointer in the second piece will be less than 65535
bytes
For TCP input processing, when a TCP packet is received with the
bit set and an Urgent field of 65535, the Urgent Pointer
calculated using an offset equal to the length of the TCP data
rather than the offset in the Urgent field
It should also be noted that though the TCP window is only 16-bits
larger windows can be used through use of the TCP Window Scale
[Jacobson92].
4. Security
There are no known security issues involved in these changes
5.
[Jacobson92] Jacobson, V., R. Braden and D. Borman, "TCP
for High Performance", RFC 1323, LBL, ISI and Cray Research,
1992.
[Deering95] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon Networks
December 1995.
Author's
David A.
Berkeley Software Design, Inc
4719 Weston Hills
Eagan, MN 55123
Phone: (612) 405-8194
Mailing List: ipng@sunroof.Eng.Sun.
Email: dab@bsdi.
Borman Standards Track [Page 3]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
