rfc2675.txt

RFC 的详细文档！

      For generating the UDP checksum, use the actual length of the UDP
      header plus data, NOT zero, in the checksum pseudo-header [IPv6,
      Section 8.1].

   The specific requirements for receiving a UDP jumbogram are as
   follows:

      When receiving a UDP packet, if and only if the Length field in
      the UDP header is zero, calculate the actual length of the UDP
      header plus data from the IPv6 Jumbo Payload Length field minus
      the length of all extension headers present between the IPv6
      header and the UDP header.

      In the unexpected case that the UDP Length field is zero but no
      Jumbo Payload option is present (i.e., the IPv6 packet is not a
      jumbogram), use the Payload Length field in the IPv6 header, in
      place of the Jumbo Payload Length field, in the above calculation.

      For verifying the received UDP checksum, use the calculated length
      of the UDP header plus data, NOT zero, in the checksum pseudo-
      header.





Borman, et al.              Standards Track                     [Page 5]

RFC 2675                    IPv6 Jumbograms                  August 1999


5. 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, and the Urgent Pointer
   cannot reference data beyond 65,535 bytes.

5.1 TCP MSS

   When determining what MSS value to send, if the MTU of the directly
   attached interface minus 60 [IPv6, Section 8.3] is greater than or
   equal to 65,535, then set the MSS value to 65,535.

   When an MSS value of 65,535 is received, it is to be treated as
   infinity.  The actual MSS is determined by subtracting 60 from the
   value learned by performing Path MTU Discovery [MTU-DISC] over the
   path to the TCP peer.

5.2 TCP Urgent Pointer

   The Urgent Pointer problem could be fixed by adding a TCP Urgent
   Pointer Option.  However, since it is unlikely that applications
   using jumbograms will also use Urgent Pointers, a less intrusive
   change similar to the MSS change will suffice.

   When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG
   bit set), first calculate the offset from the Sequence Number to the
   Urgent Pointer.  If the offset is less than 65,535, fill in the
   Urgent field and continue with the normal TCP processing.  If the
   offset is greater than 65,535, and the offset is greater than or
   equal to the length of the TCP data, fill in the Urgent Pointer with
   65,535 and continue with the normal TCP processing.  Otherwise, the
   TCP packet 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 the Urgent field is set to 65,535 to indicate that the
   Urgent Pointer is beyond the end of this packet.  The second piece
   can then be sent with the Urgent field set normally.

   Note: The first piece does not have to include all of the data up to
   the Urgent Pointer.  It can be shorter, just as long as it ends
   within 65,534 bytes of the Urgent Pointer, so that the offset to the
   Urgent Pointer in the second piece will be less than 65,535 bytes.

   For TCP input processing, when a TCP packet is received with the URG
   bit set and an Urgent field of 65,535, the Urgent Pointer is
   calculated using an offset equal to the length of the TCP data,
   rather than the offset in the Urgent field.



Borman, et al.              Standards Track                     [Page 6]

RFC 2675                    IPv6 Jumbograms                  August 1999


   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 option
   [TCP-EXT].

6. Security Considerations

   The Jumbo Payload option and TCP/UDP jumbograms do not introduce any
   known new security concerns.

7. Authors' Addresses

   David A. Borman
   Berkeley Software Design, Inc.
   4719 Weston Hills Drive
   Eagan, MN 55123
   USA

   Phone: [phone]
   EMail: [e-mail]


   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

   Phone: [phone]
   EMail: [e-mail]


   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

   Phone: [phone]
   EMail: [e-mail]












Borman, et al.              Standards Track                     [Page 7]

RFC 2675                    IPv6 Jumbograms                  August 1999


8. References

   [ICMPv6]   Conta, A. and S. Deering, "ICMP for the Internet Protocol
              Version 6 (IPv6)", RFC 2463, December 1998.

   [IPv6]     Deering, S. and R. Hinden, "Internet Protocol Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [MTU-DISC] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
              for IP Version 6", RFC 1981, August 1986.

   [TCP]      Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [TCP-EXT]  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [UDP]      Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.
































Borman, et al.              Standards Track                     [Page 8]

RFC 2675                    IPv6 Jumbograms                  August 1999


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Borman, et al.              Standards Track                     [Page 9]