rfc1981.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   size).  In many systems (such as those derived from 4.2BSD), the
   segment size is often set to 1024 octets, and the maximum window size
   (the "send space") is usually a multiple of 1024 octets, so the
   proper relationship holds by default.  If Path MTU Discovery is used,
   however, the segment size may not be a submultiple of the send space,
   and it may change during a connection; this means that the TCP layer
   may need to change the transmission window size when Path MTU
   Discovery changes the PMTU value.  The maximum window size should be
   set to the greatest multiple of the segment size that is less than or
   equal to the sender's buffer space size.

5.5. Issues for other transport protocols

   Some transport protocols (such as ISO TP4 [ISOTP]) are not allowed to
   repacketize when doing a retransmission.  That is, once an attempt is
   made to transmit a segment of a certain size, the transport cannot
   split the contents of the segment into smaller segments for
   retransmission.  In such a case, the original segment can be
   fragmented by the IP layer during retransmission.  Subsequent
   segments, when transmitted for the first time, should be no larger
   than allowed by the Path MTU.

   The Sun Network File System (NFS) uses a Remote Procedure Call (RPC)
   protocol [RPC] that, when used over UDP, in many cases will generate
   payloads that must be fragmented even for the first-hop link.  This
   might improve performance in certain cases, but it is known to cause
   reliability and performance problems, especially when the client and
   server are separated by routers.

   It is recommended that NFS implementations use Path MTU Discovery
   whenever routers are involved.  Most NFS implementations allow the
   RPC datagram size to be changed at mount-time (indirectly, by
   changing the effective file system block size), but might require
   some modification to support changes later on.

   Also, since a single NFS operation cannot be split across several UDP
   datagrams, certain operations (primarily, those operating on file
   names and directories) require a minimum payload size that if sent in
   a single packet would exceed the PMTU.  NFS implementations should
   not reduce the payload size below this threshold, even if Path MTU
   Discovery suggests a lower value.  In this case the payload will be
   fragmented by the IP layer.









McCann, Deering & Mogul     Standards Track                    [Page 11]

RFC 1981              Path MTU Discovery for IPv6            August 1996


5.6. Management interface

   It is suggested that an implementation provide a way for a system
   utility program to:

   - Specify that Path MTU Discovery not be done on a given path.

   - Change the PMTU value associated with a given path.

   The former can be accomplished by associating a flag with the path;
   when a packet is sent on a path with this flag set, the IP layer does
   not send packets larger than the IPv6 minimum link MTU.

   These features might be used to work around an anomalous situation,
   or by a routing protocol implementation that is able to obtain Path
   MTU values.

   The implementation should also provide a way to change the timeout
   period for aging stale PMTU information.

6. Security Considerations

   This Path MTU Discovery mechanism makes possible two denial-of-
   service attacks, both based on a malicious party sending false Packet
   Too Big messages to a node.

   In the first attack, the false message indicates a PMTU much smaller
   than reality.  This should not entirely stop data flow, since the
   victim node should never set its PMTU estimate below the IPv6 minimum
   link MTU.  It will, however, result in suboptimal performance.

   In the second attack, the false message indicates a PMTU larger than
   reality.  If believed, this could cause temporary blockage as the
   victim sends packets that will be dropped by some router.  Within one
   round-trip time, the node would discover its mistake (receiving
   Packet Too Big messages from that router), but frequent repetition of
   this attack could cause lots of packets to be dropped.  A node,
   however, should never raise its estimate of the PMTU based on a
   Packet Too Big message, so should not be vulnerable to this attack.

   A malicious party could also cause problems if it could stop a victim
   from receiving legitimate Packet Too Big messages, but in this case
   there are simpler denial-of-service attacks available.








McCann, Deering & Mogul     Standards Track                    [Page 12]

RFC 1981              Path MTU Discovery for IPv6            August 1996


Acknowledgements

   We would like to acknowledge the authors of and contributors to
   [RFC-1191], from which the majority of this document was derived.  We
   would also like to acknowledge the members of the IPng working group
   for their careful review and constructive criticisms.













































McCann, Deering & Mogul     Standards Track                    [Page 13]

RFC 1981              Path MTU Discovery for IPv6            August 1996


Appendix A - Comparison to RFC 1191

   This document is based in large part on RFC 1191, which describes
   Path MTU Discovery for IPv4.  Certain portions of RFC 1191 were not
   needed in this document:

   router specification    - Packet Too Big messages and corresponding
                             router behavior are defined in [ICMPv6]

   Don't Fragment bit      - there is no DF bit in IPv6 packets

   TCP MSS discussion      - selecting a value to send in the TCP MSS
                             option is discussed in [IPv6-SPEC]

   old-style messages      - all Packet Too Big messages report the
                             MTU of the constricting link

   MTU plateau tables      - not needed because there are no old-style
                             messages

References

   [CONG]      Van Jacobson.  Congestion Avoidance and Control.  Proc.
               SIGCOMM '88 Symposium on Communications Architectures and
               Protocols, pages 314-329.  Stanford, CA, August, 1988.

   [FRAG]      C. Kent and J. Mogul.  Fragmentation Considered Harmful.
               In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
               Communications Technology.  August, 1987.

   [ICMPv6]    Conta, A., and S. Deering, "Internet Control Message
               Protocol (ICMPv6) for the Internet Protocol Version 6
               (IPv6) Specification", RFC 1885, December 1995.

   [IPv6-SPEC] Deering, S., and R. Hinden, "Internet Protocol, Version
               6 (IPv6) Specification", RFC 1883, December 1995.

   [ISOTP]     ISO.  ISO Transport Protocol Specification: ISO DP 8073.
               RFC 905, SRI Network Information Center, April, 1984.

   [ND]        Narten, T., Nordmark, E., and W. Simpson, "Neighbor
               Discovery for IP Version 6 (IPv6)", Work in Progress.

   [RFC-1191]  Mogul, J., and S. Deering, "Path MTU Discovery",
               RFC 1191, November 1990.






McCann, Deering & Mogul     Standards Track                    [Page 14]

RFC 1981              Path MTU Discovery for IPv6            August 1996


   [RPC]       Sun Microsystems, Inc., "RPC: Remote Procedure Call
               Protocol", RFC 1057, SRI Network Information Center,
               June, 1988.

Authors' Addresses

   Jack McCann
   Digital Equipment Corporation
   110 Spitbrook Road, ZKO3-3/U14
   Nashua, NH 03062
   Phone: [phone]

   Fax:   [phone]
   Email: [e-mail]


   Stephen E. Deering
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   Phone: [phone]

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


   Jeffrey Mogul
   Digital Equipment Corporation Western Research Laboratory
   250 University Avenue
   Palo Alto, CA 94301
   Phone: [phone]

   EMail: [e-mail]


















McCann, Deering & Mogul     Standards Track                    [Page 15]