RFC2923 日本語訳
2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000. (Format: TXT=30976 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Lahey Request for Comments: 2923 dotRocket, Inc. Category: Informational September 2000
コメントを求めるワーキンググループK.レーヒーの要求をネットワークでつないでください: 2923年のdotRocket Inc.カテゴリ: 情報の2000年9月
TCP Problems with Path MTU Discovery
経路MTU発見に関するTCP問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU.
このメモは伸びacknowlegements(ACKs)はMaximum Segment Size(MSS)とセグメントサイズの間の混乱のため長年のブラックホール問題を含むPath Maximum Transmission Unitディスカバリー(PMTUD)を取扱って、PMTUに基づいてMSS広告を取扱うことにおけるいくつかの知られている通信制御プロトコル(TCP)実現問題をカタログに載せます。
1. Introduction
1. 序論
This memo catalogs several known TCP implementation problems dealing with Path MTU Discovery [RFC1191], including the long-standing black hole problem, stretch ACKs due to confusion between MSS and segment size, and MSS advertisement based on PMTU. The goal in doing so is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations.
このメモはPath MTUディスカバリー[RFC1191]に対処することにおけるいくつかの知られているTCP実現問題をカタログに載せます、長年のブラックホール問題、MSSの間の混乱による伸びACKsとセグメントサイズ、およびPMTUに基づくMSS広告を含んでいて。 そうすることにおける目標は既存のインターネットで現在のTCP/IPインプリメンテーションの品質を高めることによって状態を改良することです。
While Path MTU Discovery (PMTUD) can be used with any upper-layer protocol, it is most commonly used by TCP; this document does not attempt to treat problems encountered by other upper-layer protocols. Path MTU Discovery for IPv6 [RFC1981] treats only IPv6-dependent issues, but not the TCP issues brought up in this document.
どんな上側の層のプロトコルと共にもPath MTUディスカバリー(PMTUD)を使用できますが、それはTCPによって最も一般的に使用されます。 このドキュメントは、他の上側の層のプロトコルによって行きあたられる問題を扱うのを試みません。 IPv6[RFC1981]のための経路MTUディスカバリーは本書では持って来られたTCP問題ではなく、IPv6依存する問題だけを扱います。
Each problem is defined as follows:
各問題は以下の通り定義されます:
Name of Problem
The name associated with the problem. In this memo, the name is
given as a subsection heading.
名前、Problemでは、名前は問題と交際しました。 このメモでは、小区分見出しとして名前を与えます。
Lahey Informational [Page 1] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[1ページ]のRFC2923TCP問題
Classification
One or more problem categories for which the problem is
classified: "congestion control", "performance", "reliability",
"non-interoperation -- connectivity failure".
問題が分類されている分類Oneか、より多くの問題カテゴリ: 「輻輳制御」、「性能」、「信頼性」、「非interoperation--、接続性失敗、」
Description
A definition of the problem, succinct but including necessary
background material.
問題の記述A定義、簡潔な、しかし、包含必要なバックグラウンドの材料。
Significance
A brief summary of the sorts of environments for which the problem
is significant.
問題が重要である環境の種類の意味のA簡潔な概要。
Implications
Why the problem is viewed as a problem.
問題が問題として見なされるという含意Why。
Relevant RFCs
The RFCs defining the TCP specification with which the problem
conflicts. These RFCs often qualify behavior using terms such as
MUST, SHOULD, MAY, and others written capitalized. See RFC 2119
for the exact interpretation of these terms.
問題が闘争するTCP仕様を定義する関連RFCs RFCs。 これらのRFCsはしばしば資格を得ます。SHOULD、使用がそのようなものを呼ぶ振舞いがそうしなければならない、5月、および大文字で書かれた状態で書かれている他のもの。 これらの用語の正確な解釈に関してRFC2119を見てください。
Trace file demonstrating the problem
One or more ASCII trace files demonstrating the problem, if
applicable.
問題を示して、適切であるなら、問題Oneのデモをするファイルか、より多くのASCII跡のファイルをたどってください。
Trace file demonstrating correct behavior
One or more examples of how correct behavior appears in a trace,
if applicable.
振舞いが跡でどれくらい正しく見えるかに関する正しい振舞いOneか、より多くの例のデモをして、適切であるなら、ファイルをたどってください。
References
References that further discuss the problem.
さらに問題について議論する参照References。
How to detect
How to test an implementation to see if it exhibits the problem.
This discussion may include difficulties and subtleties associated
with causing the problem to manifest itself, and with interpreting
traces to detect the presence of the problem (if applicable).
それが問題を示すかどうかを見るために実現をテストするためにHowを検出する方法。 この議論は困難と問題が現れることを引き起こして、問題の存在を検出するために跡を解釈すると関連している微妙さを含むかもしれません(適切であるなら)。
How to fix
For known causes of the problem, how to correct the
implementation.
問題のFor知られている原因、どう実現を修正するかを修理する方法。
Lahey Informational [Page 2] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[2ページ]のRFC2923TCP問題
2. Known implementation problems
2. 知られている実現問題
2.1.
2.1.
Name of Problem
Black Hole Detection
問題ブラックホール検出の名前
Classification
Non-interoperation -- connectivity failure
分類Non-interoperation--接続性失敗
Description
A host performs Path MTU Discovery by sending out as large a
packet as possible, with the Don't Fragment (DF) bit set in the IP
header. If the packet is too large for a router to forward on to
a particular link, the router must send an ICMP Destination
Unreachable -- Fragmentation Needed message to the source address.
The host then adjusts the packet size based on the ICMP message.
記述Aホストは、どんなFragment(DF)ビットもIPヘッダーに設定しなかったドンでできるだけ大きいパケットを出すことによって、Path MTUディスカバリーを実行します。 パケットがルータが特定のリンクに送ることができないくらい大きいなら、ルータはICMP Destination Unreachableを送らなければなりません--断片化はソースアドレスにメッセージを必要としました。 そして、ホストはICMPメッセージに基づくパケットサイズを調整します。
As was pointed out in [RFC1435], routers don't always do this
correctly -- many routers fail to send the ICMP messages, for a
variety of reasons ranging from kernel bugs to configuration
problems. Firewalls are often misconfigured to suppress all ICMP
messages. IPsec [RFC2401] and IP-in-IP [RFC2003] tunnels
shouldn't cause these sorts of problems, if the implementations
follow the advice in the appropriate documents.
[RFC1435]で指摘されたように、ルータはいつも正しくこれをするというわけではありません--多くのルータはICMPメッセージを送りません、カーネルバグから設定問題まで及ぶさまざまな理由で。ファイアウォールは、すべてのICMPメッセージを削除するためにしばしばmisconfiguredされます。 IPsec[RFC2401]とIPにおけるIP[RFC2003]トンネルはこれらの種類の問題を引き起こすはずがありません、実現が適切なドキュメントにおけるアドバイスに従うなら。
PMTUD, as documented in [RFC1191], fails when the appropriate ICMP
messages are not received by the originating host. The upper-
layer protocol continues to try to send large packets and, without
the ICMP messages, never discovers that it needs to reduce the
size of those packets. Its packets are disappearing into a PMTUD
black hole.
適切なICMPメッセージが送信元ホストによって受け取られないとき、[RFC1191]に記録されるPMTUDは失敗します。 上側の層のプロトコルは、大きいパケットを送ろうとし続けて、ICMPメッセージなしでそれが、それらのパケットのサイズを減少させる必要であると決して発見しません。 パケットはPMTUDブラックホールの中に見えなくなっています。
Significance
When PMTUD fails due to the lack of ICMP messages, TCP will also
completely fail under some conditions.
意味When PMTUDはICMPメッセージの不足のため失敗します、また、TCPはいくつかの条件のもとで完全に失敗するでしょう。
Implications
This failure is especially difficult to debug, as pings and some
interactive TCP connections to the destination host work. Bulk
transfers fail with the first large packet and the connection
eventually times out.
Thisの故障はピングと何人かの対話的なTCP接続としてあて先ホストにデバッグするのが特に難しいという含意は働いています。 最初の大きいパケットと接続に応じて、バルク転送は外で結局回に失敗します。
These situations can almost always be blamed on a misconfiguration
within the network, which should be corrected. However it seems
inappropriate for some TCP implementations to suffer
ネットワークの中でほとんどいつもこれらの状況をmisconfigurationのせいにすることができます。ネットワークは修正されるべきです。 しかしながら、いくつかのTCP実現に苦しむように不適当に思えます。
Lahey Informational [Page 3] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[3ページ]のRFC2923TCP問題
interoperability failures over paths which do not affect other TCP
implementations (i.e. those without PMTUD). This creates a market
disincentive for deploying TCP implementation with PMTUD enabled.
他のTCP実現(すなわち、PMTUDのないそれら)に影響しない経路の上の相互運用性失敗。 これは、PMTUDが有効にされている状態でTCP実現を配備するために市場行動を妨げるものを作成します。
Relevant RFCs
RFC 1191 describes Path MTU Discovery. RFC 1435 provides an early
description of these sorts of problems.
関連RFCs RFC1191はPath MTUディスカバリーについて説明します。 RFC1435はこれらの種類の問題の早めの記述を提供します。
Trace file demonstrating the problem
Made using tcpdump [Jacobson89] recording at an intermediate host.
中間的ホストに記録しながらtcpdump[Jacobson89]を使用することにおける問題Madeのデモをして、ファイルをたどってください。
20:12:11.951321 A > B: S 1748427200:1748427200(0)
win 49152 <mss 1460>
20:12:11.951829 B > A: S 1001927984:1001927984(0)
ack 1748427201 win 16384 <mss 65240>
20:12:11.955230 A > B: . ack 1 win 49152 (DF)
20:12:11.959099 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:13.139074 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:16.188685 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:22.290483 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:34.491856 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:12:58.896405 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:13:47.703184 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:14:52.780640 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:15:57.856037 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:17:02.932431 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:18:08.009337 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:19:13.090521 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:20:18.168066 A > B: . 1:1461(1460) ack 1 win 49152 (DF)
20:21:23.242761 A > B: R 1461:1461(0) ack 1 win 49152 (DF)
20:12: 11.951321 >B: S1748427200: 1748427200(0)勝利49152<mss1460>20:12:11.951829B>A: S1001927984: 1001927984(0) ack1748427201は16384<mss65240>20:12:11.955230A>Bを獲得します: . ack1は49152(DF)20:12:11.959099A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:12:13.139074A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:12:16.188685A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:12:22.290483A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:12:34.491856A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:12:58.896405A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:13:47.703184A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:14:52.780640A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:15:57.856037A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:17:02.932431A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:18:08.009337A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:19:13.090521A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:20:18.168066A>Bを獲得します: . 1:1461(1460)ack1は49152(DF)20:21:23.242761A>Bを獲得します: R1461: 1461(0) ack1は49152を獲得します。(DF)
The short SYN packet has no trouble traversing the network, due to
its small size. Similarly, ICMP echo packets used to diagnose
connectivity problems will succeed.
脆いSYNパケットは小型のためネットワークを横断するのに全く苦労しません。 同様に、接続性問題を診断するのに使用されるICMPエコーパケットは成功するでしょう。
Large data packets fail to traverse the network. Eventually the
connection times out. This can be especially confusing when the
application starts out with a very small write, which succeeds,
following up with many large writes, which then fail.
大きいデータ・パケットはネットワークを横断しません。 結局接続回のアウト。 アプリケーション始め(成功する)がaが非常に小さい外に書くとき、これは特に混乱させられることができて、多くが大きい状態で追求するのは書きます(その時、失敗します)。
Trace file demonstrating correct behavior
正しい振舞いを示す跡のファイル
Made using tcpdump recording at an intermediate host.
中間的ホストに記録するtcpdumpを使用することで、作られています。
16:48:42.659115 A > B: S 271394446:271394446(0)
win 8192 <mss 1460> (DF)
16:48:42.672279 B > A: S 2837734676:2837734676(0)
ack 271394447 win 16384 <mss 65240>
16:48: 42.659115 >B: S271394446: 271394446(0)勝利8192<mss1460>(DF)16:48:42.672279B>A: S2837734676: 2837734676(0) ack271394447は16384<mss65240>を獲得します。
Lahey Informational [Page 4] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[4ページ]のRFC2923TCP問題
16:48:42.676890 A > B: . ack 1 win 8760 (DF)
16:48:42.870574 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
16:48:42.871799 A > B: . 1461:2921(1460) ack 1 win 8760 (DF)
16:48:45.786814 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
16:48:51.794676 A > B: . 1:1461(1460) ack 1 win 8760 (DF)
16:49:03.808912 A > B: . 1:537(536) ack 1 win 8760
16:49:04.016476 B > A: . ack 537 win 16384
16:49:04.021245 A > B: . 537:1073(536) ack 1 win 8760
16:49:04.021697 A > B: . 1073:1609(536) ack 1 win 8760
16:49:04.120694 B > A: . ack 1609 win 16384
16:49:04.126142 A > B: . 1609:2145(536) ack 1 win 8760
16:48: 42.676890 >B: . ack1は8760(DF)16:48:42.870574A>Bを獲得します: . 1:1461(1460)ack1は8760(DF)16:48:42.871799A>Bを獲得します: . 1461:2921 (1460)ack1は8760(DF)16:48:45.786814A>Bを獲得します: . 1:1461(1460)ack1は8760(DF)16:48:51.794676A>Bを獲得します: . 1:1461(1460)ack1は8760(DF)16:49:03.808912A>Bを獲得します: . 1: 537(536) ack1は8760 16:49:04.016476B>A:を獲得します。 . ack537は16384 16:49:04.021245A>Bを獲得します: . 537: 1073(536) ack1は8760 16:49:04.021697A>Bを獲得します: . 1073: 1609(536) ack1は8760 16:49:04.120694B>A:を獲得します。 . ack1609は16384 16:49:04.126142A>Bを獲得します: . 1609: 2145(536) ack1は8760を獲得します。
In this case, the sender sees four packets fail to traverse the
network (using a two-packet initial send window) and turns off
PMTUD. All subsequent packets have the DF flag turned off, and
the size set to the default value of 536 [RFC1122].
この場合、送付者は、4つのパケットがネットワーク(初期で2パケットを使用して、窓を送る)を横断しないのを見て、PMTUDをオフにします。 すべてのその後のパケットでDF旗をオフにします、そして、サイズは536[RFC1122]のデフォルト値にセットしました。
References
This problem has been discussed extensively on the tcp-impl
mailing list; the name "black hole" has been in use for many
years.
tcp-implメーリングリストで手広く参照This問題について議論しました。 名前「ブラックホール」は何年間も使用中です。
How to detect
This shows up as a TCP connection which hangs (fails to make
progress) until closed by timeout (this often manifests itself as
a connection that connects and starts to transfer, then eventually
terminates after 15 minutes with zero bytes transfered). This is
particularly annoying with an application like ftp, which will
work perfectly while it uses small packets for control
information, and then fail on bulk transfers.
どうThisを検出するかはタイムアウトによって閉じられるまで掛かる(進展しません)TCP接続として現れます(これは、接続して、移し始める接続としてしばしば現れて、次に、バイトが全くtransferedされていなく、15分後に結局、終わります)。 これは特にftpのようなアプリケーションに煩わしいです。(ftpは制御情報に小型小包を使用している間、完全に働いて、次に、バルク転送のときに失敗するでしょう)。
A series of ICMP echo packets will show that the two end hosts are
still capable of passing packets, a series of MTU-sized ICMP echo
packets will show some fragmentation, and a series of MTU-sized
ICMP echo packets with DF set will fail. This can be confusing
for network engineers trying to diagnose the problem.
一連のICMPエコーパケットが、2人の終わりのホストはパケットを通過するのがまだできているのを示すでしょう、そして、一連のMTUサイズのICMPエコーパケットが何らかの断片化を示すでしょう、そして、DFがセットしたことでの一連のMTUサイズのICMPエコーパケットが失敗するでしょう。 これは問題を診断しようとするネットワーク・デザイナーのために混乱させられることができます。
There are several traceroute implementations that do PMTUD, and
can demonstrate the problem.
問題は、PMTUDをするいくつかのトレースルート実現であり、示されることができます。
How to fix
TCP should notice that the connection is timing out. After
several timeouts, TCP should attempt to send smaller packets,
perhaps turning off the DF flag for each packet. If this
succeeds, it should continue to turn off PMTUD for the connection
for some reasonable period of time, after which it should probe
again to try to determine if the path has changed.
どうTCPを修理するかは、接続が外で調節しているのに気付くべきです。 数回のタイムアウトの後に、各パケットのために恐らくDF旗をオフにして、TCPは、より小さいパケットを送るのを試みるはずです。 これが成功するなら、それは、接続のためにいつかの適正な期間の間、PMTUDをオフにし続けるべきです。(その時、それは、経路が変化したかどうか決定しようとするために再び調べられたべきでした後)。
Lahey Informational [Page 5] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[5ページ]のRFC2923TCP問題
Note that, under IPv6, there is no DF bit -- it is implicitly on
at all times. Fragmentation is not allowed in routers, only at
the originating host. Fortunately, the minimum supported MTU for
IPv6 is 1280 octets, which is significantly larger than the 68
octet minimum in IPv4. This should make it more reasonable for
IPv6 TCP implementations to fall back to 1280 octet packets, when
IPv4 implementations will probably have to turn off DF to respond
to black hole detection.
IPv6の下にDFビットが全くないことに注意してください--それはいつもそれとなくオンです。 断片化は送信元ホストだけでルータで許されていません。 幸い、IPv6のための最小の支持されたMTUは1280の八重奏です(68八重奏最小限よりかなりIPv4で大きいです)。 これで、IPv6 TCP実現が1280の八重奏パケットまで後ろへ下がるのが、より妥当になるべきです、IPv4実現がブラックホール検出に応じるためにたぶんDFをオフにしなければならないと。
Ideally, the ICMP black holes should be fixed when they are found.
それらが見つけられるとき、理想的に、ICMPブラックホールは修理されるべきです。
If hosts start to implement black hole detection, it may be that
these problems will go unnoticed and unfixed. This is especially
unfortunate, since detection can take several seconds each time,
and these delays could result in a significant, hidden degradation
of performance. Hosts that implement black hole detection should
probably log detected black holes, so that they can be fixed.
ホストがブラックホール検出を実行し始めるなら、これらの問題は、多分、見つからずに済んで、非修理されました。 これは特に不幸です、検出が各回数秒取ることができて、これらの遅れが性能の重要で、隠された退行をもたらすかもしれないので。 道具ブラックホール検出がたぶん登録するべきであるホストは、それらを修理できるようにブラックホールを検出しました。
2.2.
2.2.
Name of Problem
Stretch ACK due to PMTUD
PMTUDによるProblem Stretch ACKという名前
Classification
Congestion Control / Performance
分類輻輳制御/パフォーマンス
Description
When a naively implemented TCP stack communicates with a PMTUD
equipped stack, it will try to generate an ACK for every second
full-sized segment. If it determines the full-sized segment based
on the advertised MSS, this can degrade badly in the face of
PMTUD.
純真に実行されたTCPスタックが備えているPMTUDと伝える記述Whenは積み重ねて、それはあらゆる2番目の完全サイズのセグメントのためにACKを発生させようとするでしょう。 広告を出しているMSSに基づく完全サイズのセグメントを決定するなら、これはPMTUDに直面してひどく退行できます。
The PMTU can wind up being a small fraction of the advertised MSS;
in this case, an ACK would be generated only very infrequently.
結局、PMTUは広告を出しているMSSのわずかな部分であるかもしれません。 この場合、ACKは非常にまれにだけ発生するでしょう。
Significance
意味
Stretch ACKs have a variety of unfortunate effects, more fully
outlined in [RFC2525]. Most of these have to do with encouraging
a more bursty connection, due to the infrequent arrival of ACKs.
They can also impede congestion window growth.
伸びACKsには、[RFC2525]により完全に概説されたさまざまな不幸な効果があります。 これらの大部分はACKsの珍しい到着のため励みになっているaよりburstyな接続と関係があります。 また、混雑窓のそれら安が成長の妨げとなることができます。
Implications
含意
The complete implications of stretch ACKs are outlined in
[RFC2525].
伸びACKsの完全な含意は[RFC2525]に概説されています。
Lahey Informational [Page 6] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[6ページ]のRFC2923TCP問題
Relevant RFCs
RFC 1122 outlines the requirements for frequency of ACK
generation. [RFC2581] expands on this and clarifies that delayed
ACK is a SHOULD, not a MUST.
関連RFCs RFC1122はACK世代の頻度のための要件について概説します。 [RFC2581]は、これについて詳述して、それをはっきりさせます。遅れたACKがSHOULDである、どんなaもそうしてはいけません。
Trace file demonstrating it
それを示す跡のファイル
Made using tcpdump recording at an intermediate host. The
timestamp options from all but the first two packets have been
removed for clarity.
中間的ホストに記録するtcpdumpを使用することで、作られています。 明快ために最初の2つのパケット以外のすべてからのタイムスタンプオプションを取り除きました。
18:16:52.976657 A > B: S 3183102292:3183102292(0) win 16384
<mss 4312,nop,wscale 0,nop,nop,timestamp 12128 0> (DF)
18:16:52.979580 B > A: S 2022212745:2022212745(0) ack 3183102293 win
49152 <mss 4312,nop,wscale 1,nop,nop,timestamp 1592957 12128> (DF)
18:16:52.979738 A > B: . ack 1 win 17248 (DF)
18:16:52.982473 A > B: . 1:4301(4300) ack 1 win 17248 (DF)
18:16:52.982557 C > A: icmp: B unreachable -
need to frag (mtu 1500)! (DF)
18:16:52.985839 B > A: . ack 1 win 32768 (DF)
18:16:54.129928 A > B: . 1:1449(1448) ack 1 win 17248 (DF)
.
.
.
18:16:58.507078 A > B: . 1463941:1465389(1448) ack 1 win 17248 (DF)
18:16:58.507200 A > B: . 1465389:1466837(1448) ack 1 win 17248 (DF)
18:16:58.507326 A > B: . 1466837:1468285(1448) ack 1 win 17248 (DF)
18:16:58.507439 A > B: . 1468285:1469733(1448) ack 1 win 17248 (DF)
18:16:58.524763 B > A: . ack 1452357 win 32768 (DF)
18:16:58.524986 B > A: . ack 1461045 win 32768 (DF)
18:16:58.525138 A > B: . 1469733:1471181(1448) ack 1 win 17248 (DF)
18:16:58.525268 A > B: . 1471181:1472629(1448) ack 1 win 17248 (DF)
18:16:58.525393 A > B: . 1472629:1474077(1448) ack 1 win 17248 (DF)
18:16:58.525516 A > B: . 1474077:1475525(1448) ack 1 win 17248 (DF)
18:16:58.525642 A > B: . 1475525:1476973(1448) ack 1 win 17248 (DF)
18:16:58.525766 A > B: . 1476973:1478421(1448) ack 1 win 17248 (DF)
18:16:58.526063 A > B: . 1478421:1479869(1448) ack 1 win 17248 (DF)
18:16:58.526187 A > B: . 1479869:1481317(1448) ack 1 win 17248 (DF)
18:16:58.526310 A > B: . 1481317:1482765(1448) ack 1 win 17248 (DF)
18:16:58.526432 A > B: . 1482765:1484213(1448) ack 1 win 17248 (DF)
18:16:58.526561 A > B: . 1484213:1485661(1448) ack 1 win 17248 (DF)
18:16:58.526671 A > B: . 1485661:1487109(1448) ack 1 win 17248 (DF)
18:16:58.537944 B > A: . ack 1478421 win 32768 (DF)
18:16:58.538328 A > B: . 1487109:1488557(1448) ack 1 win 17248 (DF)
18:16: 52.976657 >B: S3183102292: 3183102292(0)勝利16384<mss4312、nop、wscale0、nop、nop、タイムスタンプ12128 0>(DF)18:16:52.979580B>A: S2022212745: 2022212745(0) ack3183102293は49152<mss4312、nop、wscale1、nop、nop、タイムスタンプ1592957 12128>(DF)18:16:52.979738A>Bを獲得します: . ack1は17248(DF)18:16:52.982473A>Bを獲得します: . 1:4301(4300)ack1は17248(DF)18:16:52.982557C>A:を獲得します。 icmp: B手の届かない、--(mtu1500)を破片手榴弾で殺傷するのが必要です! (DF) 18:16:52.985839B>A: . ack1は32768(DF)18:16:54.129928A>Bを獲得します: . 1:1449(1448)ack1は17248(DF).18:16:58.507078A>Bを獲得します: . 1463941:1465389 (1448)ack1は17248(DF)18:16:58.507200A>Bを獲得します: . 1465389:1466837 (1448)ack1は17248(DF)18:16:58.507326A>Bを獲得します: . 1466837:1468285 (1448)ack1は17248(DF)18:16:58.507439A>Bを獲得します: . 1468285:1469733 (1448)ack1は17248(DF)18:16:58.524763B>A:を獲得します。 . ack1452357は32768(DF)18:16:58.524986B>A:を獲得します。 . ack1461045は32768(DF)18:16:58.525138A>Bを獲得します: . 1469733:1471181 (1448)ack1は17248(DF)18:16:58.525268A>Bを獲得します: . 1471181:1472629 (1448)ack1は17248(DF)18:16:58.525393A>Bを獲得します: . 1472629:1474077 (1448)ack1は17248(DF)18:16:58.525516A>Bを獲得します: . 1474077:1475525 (1448)ack1は17248(DF)18:16:58.525642A>Bを獲得します: . 1475525:1476973 (1448)ack1は17248(DF)18:16:58.525766A>Bを獲得します: . 1476973:1478421 (1448)ack1は17248(DF)18:16:58.526063A>Bを獲得します: . 1478421:1479869 (1448)ack1は17248(DF)18:16:58.526187A>Bを獲得します: . 1479869:1481317 (1448)ack1は17248(DF)18:16:58.526310A>Bを獲得します: . 1481317:1482765 (1448)ack1は17248(DF)18:16:58.526432A>Bを獲得します: . 1482765:1484213 (1448)ack1は17248(DF)18:16:58.526561A>Bを獲得します: . 1484213:1485661 (1448)ack1は17248(DF)18:16:58.526671A>Bを獲得します: . 1485661:1487109 (1448)ack1は17248(DF)18:16:58.537944B>A:を獲得します。 . ack1478421は32768(DF)18:16:58.538328A>Bを獲得します: . 1487109:1488557 (1448)ack1は17248を獲得します。(DF)
Lahey Informational [Page 7] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[7ページ]のRFC2923TCP問題
Note that the interval between ACKs is significantly larger than two times the segment size; it works out to be almost exactly two times the advertised MSS. This transfer was long enough that it could be verified that the stretch ACK was not the result of lost ACK packets.
ACKsの間隔がセグメントサイズの2倍よりかなり大きいことに注意してください。 それは、ほとんどちょうど広告を出しているMSSの2倍になるように解決します。 この転送は伸びACKが無くなっているACKパケットの結果でなかったことを確かめることができるくらい長かったです。
Trace file demonstrating correct behavior
正しい振舞いを示す跡のファイル
Made using tcpdump recording at an intermediate host. The timestamp options from all but the first two packets have been removed for clarity.
中間的ホストに記録するtcpdumpを使用することで、作られています。 明快ために最初の2つのパケット以外のすべてからのタイムスタンプオプションを取り除きました。
18:13:32.287965 A > B: S 2972697496:2972697496(0)
win 16384 <mss 4312,nop,wscale 0,nop,nop,timestamp 11326 0> (DF)
18:13:32.290785 B > A: S 245639054:245639054(0)
ack 2972697497 win 34496 <mss 4312> (DF)
18:13:32.290941 A > B: . ack 1 win 17248 (DF)
18:13:32.293774 A > B: . 1:4313(4312) ack 1 win 17248 (DF)
18:13:32.293856 C > A: icmp: B unreachable -
need to frag (mtu 1500)! (DF)
18:13:33.637338 A > B: . 1:1461(1460) ack 1 win 17248 (DF)
.
.
.
18:13:35.561691 A > B: . 1514021:1515481(1460) ack 1 win 17248 (DF)
18:13:35.561814 A > B: . 1515481:1516941(1460) ack 1 win 17248 (DF)
18:13:35.561938 A > B: . 1516941:1518401(1460) ack 1 win 17248 (DF)
18:13:35.562059 A > B: . 1518401:1519861(1460) ack 1 win 17248 (DF)
18:13:35.562174 A > B: . 1519861:1521321(1460) ack 1 win 17248 (DF)
18:13:35.564008 B > A: . ack 1481901 win 64680 (DF)
18:13:35.564383 A > B: . 1521321:1522781(1460) ack 1 win 17248 (DF)
18:13:35.564499 A > B: . 1522781:1524241(1460) ack 1 win 17248 (DF)
18:13:35.615576 B > A: . ack 1484821 win 64680 (DF)
18:13:35.615646 B > A: . ack 1487741 win 64680 (DF)
18:13:35.615716 B > A: . ack 1490661 win 64680 (DF)
18:13:35.615784 B > A: . ack 1493581 win 64680 (DF)
18:13:35.615856 B > A: . ack 1496501 win 64680 (DF)
18:13:35.615952 A > B: . 1524241:1525701(1460) ack 1 win 17248 (DF)
18:13:35.615966 B > A: . ack 1499421 win 64680 (DF)
18:13:35.616088 A > B: . 1525701:1527161(1460) ack 1 win 17248 (DF)
18:13:35.616105 B > A: . ack 1502341 win 64680 (DF)
18:13:35.616211 A > B: . 1527161:1528621(1460) ack 1 win 17248 (DF)
18:13:35.616228 B > A: . ack 1505261 win 64680 (DF)
18:13:35.616327 A > B: . 1528621:1530081(1460) ack 1 win 17248 (DF)
18:13:35.616349 B > A: . ack 1508181 win 64680 (DF)
18:13:35.616448 A > B: . 1530081:1531541(1460) ack 1 win 17248 (DF)
18:13:35.616565 A > B: . 1531541:1533001(1460) ack 1 win 17248 (DF)
18:13:35.616891 A > B: . 1533001:1534461(1460) ack 1 win 17248 (DF)
18:13: 32.287965 >B: S2972697496: 2972697496(0)勝利16384<mss4312、nop、wscale0、nop、nop、タイムスタンプ11326 0>(DF)18:13:32.290785B>A: S245639054: 245639054(0) ack2972697497は34496<mss4312>(DF)18:13:32.290941A>Bを獲得します: . ack1は17248(DF)18:13:32.293774A>Bを獲得します: . 1:4313(4312)ack1は17248(DF)18:13:32.293856C>A:を獲得します。 icmp: B手の届かない、--(mtu1500)を破片手榴弾で殺傷するのが必要です! (DF) 18:13: 33.637338 >B: . 1:1461(1460)ack1は17248(DF).18:13:35.561691A>Bを獲得します: . 1514021:1515481 (1460)ack1は17248(DF)18:13:35.561814A>Bを獲得します: . 1515481:1516941 (1460)ack1は17248(DF)18:13:35.561938A>Bを獲得します: . 1516941:1518401 (1460)ack1は17248(DF)18:13:35.562059A>Bを獲得します: . 1518401:1519861 (1460)ack1は17248(DF)18:13:35.562174A>Bを獲得します: . 1519861:1521321 (1460)ack1は17248(DF)18:13:35.564008B>A:を獲得します。 . ack1481901は64680(DF)18:13:35.564383A>Bを獲得します: . 1521321:1522781 (1460)ack1は17248(DF)18:13:35.564499A>Bを獲得します: . 1522781:1524241 (1460)ack1は17248(DF)18:13:35.615576B>A:を獲得します。 . ack1484821は64680(DF)18:13:35.615646B>A:を獲得します。 . ack1487741は64680(DF)18:13:35.615716B>A:を獲得します。 . ack1490661は64680(DF)18:13:35.615784B>A:を獲得します。 . ack1493581は64680(DF)18:13:35.615856B>A:を獲得します。 . ack1496501は64680(DF)18:13:35.615952A>Bを獲得します: . 1524241:1525701 (1460)ack1は17248(DF)18:13:35.615966B>A:を獲得します。 . ack1499421は64680(DF)18:13:35.616088A>Bを獲得します: . 1525701:1527161 (1460)ack1は17248(DF)18:13:35.616105B>A:を獲得します。 . ack1502341は64680(DF)18:13:35.616211A>Bを獲得します: . 1527161:1528621 (1460)ack1は17248(DF)18:13:35.616228B>A:を獲得します。 . ack1505261は64680(DF)18:13:35.616327A>Bを獲得します: . 1528621:1530081 (1460)ack1は17248(DF)18:13:35.616349B>A:を獲得します。 . ack1508181は64680(DF)18:13:35.616448A>Bを獲得します: . 1530081:1531541 (1460)ack1は17248(DF)18:13:35.616565A>Bを獲得します: . 1531541:1533001 (1460)ack1は17248(DF)18:13:35.616891A>Bを獲得します: . 1533001:1534461 (1460)ack1は17248を獲得します。(DF)
Lahey Informational [Page 8] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[8ページ]のRFC2923TCP問題
In this trace, an ACK is generated for every two segments that arrive. (The segment size is slightly larger in this trace, even though the source hosts are the same, because of the lack of timestamp options in this trace.)
この跡では、ACKは到着する2つのセグメント毎のために発生します。 (セグメントサイズはこの跡でわずかに大きいです、送信元ホストが同じですが、この跡のタイムスタンプオプションの不足のために。)
How to detect This condition can be observed in a packet trace when the advertised MSS is significantly larger than the actual PMTU of a connection.
広告を出しているMSSが接続の実際のPMTUよりかなり大きいときに、パケット跡でどうThis状態を検出するかを観測できます。
How to fix Several solutions for this problem have been proposed:
修理するために、この問題のSeveral解決はどう提案されたか:
A simple solution is to ACK every other packet, regardless of size. This has the drawback of generating large numbers of ACKs in the face of lots of very small packets; this shows up with applications like the X Window System.
簡単な解決策はサイズにかかわらずACKへの他のあらゆるパケットです。 これには、多くの非常に小さいパケットに直面して多くのACKsを発生させる欠点があります。 これはXウィンドウシステムのようなアプリケーションと共に現れます。
A slightly more complex solution would monitor the size of incoming segments and try to determine what segment size the sender is using. This requires slightly more state in the receiver, but has the advantage of making receiver silly window syndrome avoidance computations more accurate [RFC813].
わずかに複雑な解決策は、入って来るセグメントのサイズをモニターして、送付者がどんなセグメントサイズを使用しているかを決定しようとするでしょう。 これで、受信機で、より多くの状態をわずかに必要としますが、受信機の愚かな窓のシンドローム回避を計算にする利点は、より正確になります[RFC813]。
2.3.
2.3.
Name of Problem Determining MSS from PMTU
PMTUからMSSを決定することにおける問題の名前
Classification Performance
分類パフォーマンス
Description The MSS advertised at the start of a connection should be based on the MTU of the interfaces on the system. (For efficiency and other reasons this may not be the largest MSS possible.) Some systems use PMTUD determined values to determine the MSS to advertise.
MSSが接続の始めに広告を出した記述はシステムの上のインタフェースのMTUに基づくべきです。 (効率と他の理由で、これは可能な最も大きいMSSでないかもしれません。) いくつかのシステムがMSSが広告を出すことを決定するPMTUDの決定している値を使用します。
This results in an advertised MSS that is smaller than the largest MTU the system can receive.
これはシステムが受けることができる中で最も大きいMTUより小さい広告を出しているMSSをもたらします。
Significance The advertised MSS is an indication to the remote system about the largest TCP segment that can be received [RFC879]. If this value is too small, the remote system will be forced to use a smaller segment size when sending, purely because the local system found a particular PMTU earlier.
意味、広告を出しているMSSは受け取ることができる中で最も大きいTCPセグメント[RFC879]に関するリモートシステムへの指示です。 発信するとき、この値が小さ過ぎるなら、リモートシステムはやむを得ずより小さいセグメントサイズを使用するでしょう、ローカルシステムが、より早く純粋に特定のPMTUを見つけたので。
Lahey Informational [Page 9] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[9ページ]のRFC2923TCP問題
Given the asymmetric nature of many routes on the Internet [Paxson97], it seems entirely possible that the return PMTU is different from the sending PMTU. Limiting the segment size in this way can reduce performance and frustrate the PMTUD algorithm.
インターネット[Paxson97]の多くのルートの非対称の本質を考えて、リターンPMTUが発信しているPMTUと異なっているのは完全に可能に思えます。 このようにセグメントサイズを制限するのは、性能を抑えて、PMTUDアルゴリズムをだめにすることができます。
Even if the route was symmetric, setting this artificially lowered limit on segment size will make it impossible to probe later to determine if the PMTU has changed.
ルートが左右対称であったとしても、セグメントサイズにおけるこの人工的に下ろされた限界を設定するのに、後でPMTUが変化したかどうか決定するために調べるのは不可能になるでしょう。
Implications The whole point of PMTUD is to send as large a segment as possible. If long-running connections cannot successfully probe for larger PMTU, then potential performance gains will be impossible to realize. This destroys the whole point of PMTUD.
PMTUDの全体の先が大きいとして可能であるとしてのセグメントを送ることになっている含意。 長い間走っている接続が、より大きいPMTUのために首尾よく調べることができないと、わかるのは潜在的性能向上が不可能になるでしょう。 これはPMTUDの全体の先を破壊します。
Relevant RFCs RFC 1191. [RFC879] provides a complete discussion of MSS calculations and appropriate values. Note that this practice does not violate any of the specifications in these RFCs.
関連RFCs RFC1191。 [RFC879]はMSS計算と適切な値の完全な議論を提供します。 この習慣がこれらのRFCsの仕様のいずれにも違反しないことに注意してください。
Trace file demonstrating it 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.
跡は、それを示しながら、ファイルされます。This跡は、中間的ホストで走りながらtcpdumpを使用することで作られました。 ホストA開始の2つの別々の連続した接続、A1、およびA2、B.Router Cを接待するのは、MTUボトルネックの位置です。 いつものように、すべての非SYNパケットからTCPオプションを取り除きます。
22:33:32.305912 A1 > B: S 1523306220:1523306220(0)
win 8760 <mss 1460> (DF)
22:33:32.306518 B > A1: S 729966260:729966260(0)
ack 1523306221 win 16384 <mss 65240>
22:33:32.310307 A1 > B: . ack 1 win 8760 (DF)
22:33:32.323496 A1 > B: P 1:1461(1460) ack 1 win 8760 (DF)
22:33:32.323569 C > A1: icmp: 129.99.238.5 unreachable -
need to frag (mtu 1024) (DF) (ttl 255, id 20666)
22:33:32.783694 A1 > B: . 1:985(984) ack 1 win 8856 (DF)
22:33:32.840817 B > A1: . ack 985 win 16384
22:33:32.845651 A1 > B: . 1461:2445(984) ack 1 win 8856 (DF)
22:33:32.846094 B > A1: . ack 985 win 16384
22:33:33.724392 A1 > B: . 985:1969(984) ack 1 win 8856 (DF)
22:33:33.724893 B > A1: . ack 2445 win 14924
22:33:33.728591 A1 > B: . 2445:2921(476) ack 1 win 8856 (DF)
22:33:33.729161 A1 > B: . ack 1 win 8856 (DF)
22:33:33.840758 B > A1: . ack 2921 win 16384
22:33:32.305912A1>B: S1523306220: 1523306220(0)勝利8760<mss1460>(DF)22:33:32.306518B>A1: S729966260: 729966260(0) ack1523306221は16384<mss65240>22:33:32.310307A1>Bを獲得します: . ack1は8760(DF)22:33:32.323496A1>Bを獲得します: P1:1461(1460)ack1は22:33:32.323569Cの8760(DF)>A1を獲得します: icmp: 129.99.238.5 手の届かない、--(DF)(ttl255、イド20666)22:33:32.783694A1>Bを破片手榴弾で殺傷する(mtu1024)必要性: . 1: 985(984) ack1は8856(DF)22:33:32.840817B>A1を獲得します: . ack985は16384 22:33:32.845651A1>Bを獲得します: . 1461: 2445(984) ack1は8856(DF)22:33:32.846094B>A1を獲得します: . ack985は16384 22:33:33.724392A1>Bを獲得します: . 985: 1969(984) ack1は8856(DF)22:33:33.724893B>A1を獲得します: . ack2445は14924 22:33:33.728591A1>Bを獲得します: . 2445: 2921(476) ack1は8856(DF)22:33:33.729161A1>Bを獲得します: . ack1は8856(DF)22:33:33.840758B>A1を獲得します: . ack2921は16384を獲得します。
[...]
[...]
22:33:34.238659 A1 > B: F 7301:8193(892) ack 1 win 8856 (DF) 22:33:34.239036 B > A1: . ack 8194 win 15492 22:33:34.239303 B > A1: F 1:1(0) ack 8194 win 16384
22:33:34.238659A1>B: F7301: 8193(892) ack1は8856(DF)22:33:34.239036B>A1を獲得します: . ack8194は15492 22:33:34.239303B>A1を獲得します: エフワン: 1(0) ack8194は16384を獲得します。
Lahey Informational [Page 10] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[10ページ]のRFC2923TCP問題
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)
22:33:34.242971A1>B: . ack2は8856(DF)22:33:34.454218A2>Bを獲得します: S1523591299: 1523591299(0)勝利8856<mss984>(DF)22:33:34.454617B>A2: S732408874: 732408874(0) ack1523591300は16384<mss65240>22:33:34.457516A2>Bを獲得します: . ack1は8856(DF)22:33:34.470683A2>Bを獲得します: P1: 985(984) ack1は8856(DF)22:33:34.471144B>A2を獲得します: . ack985は16384 22:33:34.476554A2>Bを獲得します: . 985: 1969(984) ack1は8856(DF)22:33:34.477580A2>Bを獲得します: P1969: 2953(984) ack1は8856を獲得します。(DF)
[...]
[...]
Notice that the SYN packet for session A2 specifies an MSS of 984.
セッションA2のためのSYNパケットが984のMSSを指定するのに注意してください。
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.
従来と同様、この跡は、中間的ホストで走りながらtcpdumpを使用することで作られました。 ホストA開始の2つの別々の連続した接続、A1、およびA2、B.Router Cを接待するのは、MTUボトルネックの位置です。 いつものように、すべての非SYNパケットからTCPオプションを取り除きます。
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)
22:36:58.828602A1>B: 3402991286(0)勝利32768<mss S3402991286:4312、wscale0、nop、タイムスタンプ、1123370309、0、1123370309>(DF)22:36:58.844040B>A1を反響してください: S946999880: 946999880(0) ack3402991287は16384<mss65240、nop、wscale0、nop、nop、タイムスタンプ429552 1123370309>22:36:58.848058A1>Bを獲得します: . ack1は32768(DF)22:36:58.851514A1>Bを獲得します: P1:1025(1024)ack1は22:36:58.851584Cの32768(DF)>A1を獲得します: icmp: 129.99.238.5 手の届かない、--(DF)22:36:58.855885A1>Bを破片手榴弾で殺傷する(mtu1024)必要性: . 1: 969(968) ack1は32768(DF)22:36:58.856378A1>Bを獲得します: . 969: 985(16) ack1は32768(DF)22:36:59.036309B>A1を獲得します: . ack985は16384 22:36:59.039255A1>Bを獲得します: FP985: 1025(40) ack1は32768(DF)22:36:59.039623B>A1を獲得します: . ack1026は16344 22:36:59.039828B>A1を獲得します: エフワン: 1(0) ack1026は16384 22:36:59.043037A1>Bを獲得します: . ack2は32768(DF)22:37:01.436032A2>Bを獲得します: 3404812097(0)勝利32768<mss S3404812097:4312、wscale0、nop、タイムスタンプ、1123372916、0、1123372916>(DF)22:37:01.436424B>A2を反響してください: S949814769: 949814769(0) ack3404812098は16384<mss65240、nop、wscale0、nop、nop、タイムスタンプ429562 1123372916>22:37:01.440147A2>Bを獲得します: . ack1は32768(DF)22:37:01.442736A2>Bを獲得します: . 1: 969(968) ack1は32768を獲得します。(DF)
Lahey Informational [Page 11] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[11ページ]のRFC2923TCP問題
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)
22:37:01.442894A2>B: P969: 985(16) ack1は32768(DF)22:37:01.443283B>A2を獲得します: . ack985は16384 22:37:01.446068A2>Bを獲得します: P985: 1025(40) ack1は32768(DF)22:37:01.446519B>A2を獲得します: . ack1025は16384 22:37:01.448465A2>Bを獲得します: F1025: 1025(0) ack1は32768(DF)22:37:01.448837B>A2を獲得します: . ack1026は16384 22:37:01.449007B>A2を獲得します: エフワン: 1(0) ack1026は16384 22:37:01.452201A2>Bを獲得します: . ack2は32768を獲得します。(DF)
Note that the same MSS was used for both session A1 and session A2.
同じMSSがセッションA1とセッション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.
2つの別々の接続のパケット跡を使用するのをどうThisを検出するかを検出できます。 1番目はPMTUDを呼び出すべきです。 PMTUが評価する1番目がどんなタイムアウトもしなかった後に2番目は間に合うようにしてすぐ、始まるはずです。
How to fix The MSS should be determined based on the MTUs of the interfaces on the system, as outlined in [RFC1122] and [RFC1191].
どうMSSを修理するかはインタフェースのMTUsに基づいてシステムの上で断固とするべきです、[RFC1122]と[RFC1191]に概説されているように。
3. Security Considerations
3. セキュリティ問題
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.
このメモで高められた1回のセキュリティ関心はICMPブラックホールがしばしばすべてのICMPメッセージを妨げる熱心過ぎたセキュリティ管理者によって引き起こされるということです。 セキュリティシステムを設計して、配備する人が上側の層のプロトコルで厳しいフィルタリングの影響を理解しているのは、きわめて重要です。 ほとんどのTCP実現がそれからデータを移すことができないなら、世界一安全なウェブサイトは価値がありません。 はるかにTCP実現のすべてを修理するよりブラックホールのすべてをむしろ修理させていてうれしいでしょう。
4. Acknowledgements
4. 承認
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.
ドキュメントを再検討するマーク・オールマン、バーン・パクソン、および寛大な助けのためのJamshid Mahdaviと、そして、様々なメカニズムの早めの提案のためのPMTUDブラックホール、およびレビューを引き起こす場合があるマット・マシスをありがとうございます。 TCP問題について説明するための構造、および構造が来ているその早めの記述[RFC2525]。 エイミーBockのおかげで特別であることで、だれが、これらを発見したPMTUDテストを実行するのを助けたかが急いで去ります。
Lahey Informational [Page 12] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[12ページ]のRFC2923TCP問題
5. References
5. 参照
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC813] Clark, D., "Window and Acknowledgement Strategy in TCP",
RFC 813, July 1982.
[RFC813] クラークと、D.と、「TCPの窓と承認戦略」、RFC813、7月1982日
[Jacobson89] V. Jacobson, C. Leres, and S. McCanne, tcpdump, June
1989, ftp.ee.lbl.gov
[Jacobson89] V.ジェーコブソン、C.LeresとS.McCanne、tcpdump、1989年6月、ftp.ee.lbl.gov
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[Paxson96] V. Paxson, "End-to-End Routing Behavior in the
Internet", IEEE/ACM Transactions on Networking (5),
pp.~601-615, Oct. 1997.
[Paxson96]V.パクソン、「インターネットの終わりから終わりへのルート設定振舞い」、Networking(5)の上のIEEE/ACM Transactions、ページ~601-615、1997年10月。
[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.
[RFC2525] PaxonとV.とオールマンとM.とドーソンとS.とフェナーとW.とGrinerとJ.と天とI.とレーヒーとK.とSemkeとI.とB.フォルツ、「知られているTCP実現問題」、RFC2525、1999年3月。
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related
Topics", RFC 879, November 1983.
[RFC879] ポステル、J.、「TCPの最大のセグメントサイズの、そして、関連の話題」、RFC879、1983年11月。
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001,
January 1997.
[RFC2001] スティーブンスと、W.と、「遅れた出発、輻輳回避が速く再送するTCP、および速い回復アルゴリズム」、RFC2001、1月1997日
Lahey Informational [Page 13] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[13ページ]のRFC2923TCP問題
6. Author's Address
6. 作者のアドレス
Kevin Lahey dotRocket, Inc. 1901 S. Bascom Ave., Suite 300 Campbell, CA 95008 USA
1901秒間ケビンレーヒーdotRocket Inc.バスコムAve、Suite300カリフォルニア95008キャンベル(米国)
Phone: +1 408-371-8977 x115 email: kml@dotrocket.com
以下に電話をしてください。 +1 408-371-8977x115メール: kml@dotrocket.com
Lahey Informational [Page 14] RFC 2923 TCP Problems with Path MTU Discovery September 2000
経路MTU発見2000年9月に関するレーヒーの情報[14ページ]のRFC2923TCP問題
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lahey Informational [Page 15]
レーヒー情報です。[15ページ]
一覧
スポンサーリンク
