home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2147.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  6.2 KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Borman
  8. Request for Comments: 2147                Berkeley Software Design, Inc.
  9. Updates: 1883                                                   May 1997
  10. Category: Standards Track
  11.  
  12.  
  13.                     TCP and UDP over IPv6 Jumbograms
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. 1.  Overview
  24.  
  25.    IPv6 supports datagrams larger than 65535 bytes long, often referred
  26.    to as jumbograms, through use of the Jumbo Payload hop-by-hop option
  27.    [Deering95].  The UDP protocol has a 16-bit length field that keeps
  28.    it from being able to make use of jumbograms, and though TCP does not
  29.    have a length field, both the MSS option and the Urgent field are
  30.    constrained by 16-bits.  This document describes some simple changes
  31.    that can be made to allow TCP and UDP to make use of IPv6 jumbograms.
  32.  
  33. 2.  UDP Jumbograms
  34.  
  35.    To allow UDP to make use of jumbograms, either the UDP length field
  36.    needs to be extended, or it needs to be ignored.  Since the size of
  37.    the field can't be changed, a length of zero is used to indicate that
  38.    it is to be ignored, and the length in the "pseudo-header" is to be
  39.    used to determine the true length of the UDP header plus data.  This
  40.    works because UDP length field includes the UDP header, so the
  41.    minimum valid value for this field is 8.
  42.  
  43.    When sending a UDP packet, if and only if the length of the UDP
  44.    header plus data is greater than 65,535, set the length field in the
  45.    UDP header to zero.
  46.  
  47.       Note 1:  The length used in the "pseudo-header" for computing the
  48.       UDP checksum is always the true length of the UDP header plus
  49.       data, NOT zero [RFC-1883, Section 8.1].
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Borman                      Standards Track                     [Page 1]
  59.  
  60. RFC 2147            TCP and UDP over IPv6 Jumbograms            May 1997
  61.  
  62.  
  63.       Note 2:  An IPv6 packet that carries a UDP packet of length
  64.       greater than 65,535 will necessarily carry a Jumbo Payload option
  65.       in a Hop-by-Hop Options header [RFC1883, Section 4.3]).  The
  66.       length field in the Jumbo Payload option contains the length of
  67.       the IP packet excluding the IPv6 header, that is, it contains the
  68.       length of all extension headers present plus the UDP header plus
  69.       the UDP data.  The length field in the IPv6 header contains zero
  70.       to indicate the presence of the Jumbo Payload option.
  71.  
  72.    If a UDP packet is received with a length field of zero, the length
  73.    of the UDP packet is computed from the length field in the Jumbo
  74.    Payload option minus the length of all extension headers present
  75.    between the IPv6 header and the UDP header.
  76.  
  77. 3.  TCP Jumbograms
  78.  
  79.    Because there is no length field in the TCP header, there is nothing
  80.    limiting the length of an individual TCP packet.  However, the MSS
  81.    value that is negotiated at the beginning of the connection limits
  82.    the largest TCP packet that can be sent, and the Urgent Pointer
  83.    cannot reference data beyond 65535 bytes.
  84.  
  85. 3.1 TCP MSS
  86.  
  87.    When determining what MSS value to send, if the MTU of the directly
  88.    attached interface is greater than 65535, then set the MSS value to
  89.    65535.
  90.  
  91.    When an MSS value of 65535 is received, it is to be treated as
  92.    infinity.  MTU discovery code, starting with the MTU of the outgoing
  93.    interface, will be used to determine the actual MSS.
  94.  
  95. 3.2 TCP Urgent Pointer
  96.  
  97.    The Urgent Pointer problem could be fixed by adding a TCP Urgent
  98.    Pointer Option.  However, since it is unlikely that applications
  99.    using jumbograms will also use Urgent Pointers, a less intrusive
  100.    change similar to the MSS change will suffice.
  101.  
  102.    When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG
  103.    bit set), first calculate the offset from the Sequence Number to the
  104.    Urgent Pointer.  If the offset is less than 65535, fill in the Urgent
  105.    field and continue with the normal TCP processing.  If the offset is
  106.    greater than 65535, and the offset is greater than or equal to the
  107.    length of the TCP data, fill in the Urgent Pointer with 65535 and
  108.    continue with the normal TCP processing.  Otherwise, the TCP packet
  109.    must be split into two pieces.  The first piece contains data up to,
  110.    but not including the data pointed to by the Urgent Pointer, and the
  111.  
  112.  
  113.  
  114. Borman                      Standards Track                     [Page 2]
  115.  
  116. RFC 2147            TCP and UDP over IPv6 Jumbograms            May 1997
  117.  
  118.  
  119.    Urgent field is set to 65535 to indicate that the Urgent Pointer is
  120.    beyond the end of this packet.  The second piece can then be sent
  121.    with the Urgent field set normally.
  122.  
  123.       Note: The first piece does not have to include all of the data up
  124.       to the Urgent Pointer.  It can be shorter, just as long as it ends
  125.       within 65534 bytes of the Urgent Pointer, so that the offset to
  126.       the Urgent Pointer in the second piece will be less than 65535
  127.       bytes.
  128.  
  129.    For TCP input processing, when a TCP packet is received with the URG
  130.    bit set and an Urgent field of 65535, the Urgent Pointer is
  131.    calculated using an offset equal to the length of the TCP data,
  132.    rather than the offset in the Urgent field.
  133.  
  134.    It should also be noted that though the TCP window is only 16-bits,
  135.    larger windows can be used through use of the TCP Window Scale option
  136.    [Jacobson92].
  137.  
  138. 4.  Security Considerations
  139.  
  140.    There are no known security issues involved in these changes.
  141.  
  142. 5.  References
  143.  
  144.    [Jacobson92] Jacobson, V., R. Braden and D. Borman, "TCP Extensions
  145.    for High Performance", RFC 1323, LBL, ISI and Cray Research, May
  146.    1992.
  147.  
  148.    [Deering95] Deering, S. and R. Hinden, "Internet Protocol, Version 6
  149.    (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon Networks,
  150.    December 1995.
  151.  
  152. Author's Address
  153.  
  154.    David A. Borman
  155.    Berkeley Software Design, Inc.
  156.    4719 Weston Hills Drive
  157.    Eagan, MN 55123
  158.    Phone: (612) 405-8194
  159.    Mailing List: ipng@sunroof.Eng.Sun.COM
  160.    Email: dab@bsdi.com
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Borman                      Standards Track                     [Page 3]
  171.  
  172.