rfc2923.txt

RFC 的详细文档！

   22:33:34.242971 A1 > B: . ack 2 win 8856 (DF)
   22:33:34.454218 A2 > B: S 1523591299:1523591299(0)
        win 8856 <mss 984> (DF)
   22:33:34.454617 B > A2: S 732408874:732408874(0)
        ack 1523591300 win 16384 <mss 65240>
   22:33:34.457516 A2 > B: . ack 1 win 8856 (DF)
   22:33:34.470683 A2 > B: P 1:985(984) ack 1 win 8856 (DF)
   22:33:34.471144 B > A2: . ack 985 win 16384
   22:33:34.476554 A2 > B: . 985:1969(984) ack 1 win 8856 (DF)
   22:33:34.477580 A2 > B: P 1969:2953(984) ack 1 win 8856 (DF)

   [...]

   Notice that the SYN packet for session A2 specifies an MSS of 984.

   Trace file demonstrating correct behavior

   As before, this trace was made using tcpdump running on an
   intermediate host.  Host A initiates two separate consecutive
   connections, A1 and A2, to host B.  Router C is the location of the
   MTU bottleneck.  As usual, TCP options are removed from all non-SYN
   packets.

   22:36:58.828602 A1 > B: S 3402991286:3402991286(0) win 32768
        <mss 4312,wscale 0,nop,timestamp 1123370309 0,
         echo 1123370309> (DF)
   22:36:58.844040 B > A1: S 946999880:946999880(0)
        ack 3402991287 win 16384
        <mss 65240,nop,wscale 0,nop,nop,timestamp 429552 1123370309>
   22:36:58.848058 A1 > B: . ack 1 win 32768  (DF)
   22:36:58.851514 A1 > B: P 1:1025(1024) ack 1 win 32768  (DF)
   22:36:58.851584 C > A1: icmp: 129.99.238.5 unreachable -
        need to frag (mtu 1024) (DF)
   22:36:58.855885 A1 > B: . 1:969(968) ack 1 win 32768  (DF)
   22:36:58.856378 A1 > B: . 969:985(16) ack 1 win 32768  (DF)
   22:36:59.036309 B > A1: . ack 985 win 16384
   22:36:59.039255 A1 > B: FP 985:1025(40) ack 1 win 32768  (DF)
   22:36:59.039623 B > A1: . ack 1026 win 16344
   22:36:59.039828 B > A1: F 1:1(0) ack 1026 win 16384
   22:36:59.043037 A1 > B: . ack 2 win 32768  (DF)
   22:37:01.436032 A2 > B: S 3404812097:3404812097(0) win 32768
        <mss 4312,wscale 0,nop,timestamp 1123372916 0,
         echo 1123372916> (DF)
   22:37:01.436424 B > A2: S 949814769:949814769(0)
        ack 3404812098 win 16384
        <mss 65240,nop,wscale 0,nop,nop,timestamp 429562 1123372916>
   22:37:01.440147 A2 > B: . ack 1 win 32768  (DF)
   22:37:01.442736 A2 > B: . 1:969(968) ack 1 win 32768  (DF)



Lahey                        Informational                     [Page 11]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


   22:37:01.442894 A2 > B: P 969:985(16) ack 1 win 32768  (DF)
   22:37:01.443283 B > A2: . ack 985 win 16384
   22:37:01.446068 A2 > B: P 985:1025(40) ack 1 win 32768  (DF)
   22:37:01.446519 B > A2: . ack 1025 win 16384
   22:37:01.448465 A2 > B: F 1025:1025(0) ack 1 win 32768  (DF)
   22:37:01.448837 B > A2: . ack 1026 win 16384
   22:37:01.449007 B > A2: F 1:1(0) ack 1026 win 16384
   22:37:01.452201 A2 > B: . ack 2 win 32768  (DF)

   Note that the same MSS was used for both session A1 and session A2.

   How to detect
   This can be detected using a packet trace of two separate
   connections;  the first should invoke PMTUD; the second should start
   soon enough after the first that the PMTU value does not time out.

   How to fix
   The MSS should be determined based on the MTUs of the interfaces on
   the system, as outlined in [RFC1122] and [RFC1191].

3. Security Considerations

   The one security concern raised by this memo is that ICMP black holes
   are often caused by over-zealous security administrators who block
   all ICMP messages.  It is vitally important that those who design and
   deploy security systems understand the impact of strict filtering on
   upper-layer protocols.  The safest web site in the world is worthless
   if most TCP implementations cannot transfer data from it.  It would
   be far nicer to have all of the black holes fixed rather than fixing
   all of the TCP implementations.

4. Acknowledgements

   Thanks to Mark Allman, Vern Paxson, and Jamshid Mahdavi for generous
   help reviewing the document, and to Matt Mathis for early suggestions
   of various mechanisms that can cause PMTUD black holes, as well as
   review.  The structure for describing TCP problems, and the early
   description of that structure is from [RFC2525].  Special thanks to
   Amy Bock, who helped perform the PMTUD tests which discovered these
   bugs.











Lahey                        Informational                     [Page 12]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


5. References

   [RFC2581]    Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
                Control", RFC 2581, April 1999.

   [RFC1122]    Braden, R., "Requirements for Internet Hosts --
                Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC813]     Clark, D., "Window and Acknowledgement Strategy in TCP",
                RFC 813, July 1982.

   [Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump, June
                1989, ftp.ee.lbl.gov

   [RFC1435]    Knowles, S., "IESG Advice from Experience with Path MTU
                Discovery", RFC 1435, March 1993.

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

   [RFC1981]    McCann, J., Deering, S. and J. Mogul, "Path MTU
                Discovery for IP version 6", RFC 1981, August 1996.

   [Paxson96]   V. Paxson, "End-to-End Routing Behavior in the
                Internet", IEEE/ACM Transactions on Networking (5),
                pp.~601-615, Oct. 1997.

   [RFC2525]    Paxon, V., Allman, M., Dawson, S., Fenner, W., Griner,
                J., Heavens, I., Lahey, K., Semke, I. and B. Volz,
                "Known TCP Implementation Problems", RFC 2525, March
                1999.

   [RFC879]     Postel, J., "The TCP Maximum Segment Size and Related
                Topics", RFC 879, November 1983.

   [RFC2001]    Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
                Retransmit, and Fast Recovery Algorithms", RFC 2001,
                January 1997.













Lahey                        Informational                     [Page 13]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


6. Author's Address

   Kevin Lahey
   dotRocket, Inc.
   1901 S. Bascom Ave., Suite 300
   Campbell, CA 95008
   USA

   Phone:  [phone] x115
   email:  [e-mail]









































Lahey                        Informational                     [Page 14]

RFC 2923          TCP Problems with Path MTU Discovery    September 2000


7.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Lahey                        Informational                     [Page 15]