RFC 2923 - TCP Problems with Path MTU Discovery 日本語訳

URL : https://tools.ietf.org/html/rfc2923
タイトル : RFC 2923 - パスMTUディスカバリとTCPの問題
翻訳編集 : 自動生成

Network Working Group                                        K. Lahey
Request for Comments: 2923                            dotRocket, Inc.
Category: Informational                                September 2000

                  TCP Problems with Path MTU Discovery

Status of this 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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2000）。全著作権所有。

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.

このメモは長年のブラックホール問題を含むパスの最大転送単位ディスカバリー（PMTUD）を扱ういくつかの既知の伝送制御プロトコル（TCP）の実装の問題は、最大セグメントサイズ（MSS）およびセグメント間による混乱をacknowlegements（ACKを）伸ばすカタログPMTUに基づいてサイズ、およびMSS広告。

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.

このメモは長年のブラックホール問題、PMTUに基づいたMSSとセグメントサイズ、およびMSS広告の混同によるストレッチのACKを含むパスMTUディスカバリー[RFC1191]に対処するいくつかの既知のTCPの実装上の問題を、カタログ。そうすることで目標は、現在の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.

パスMTUディスカバリ（PMTUD）は、任意の上位層プロトコルで使用することができるが、それは、最も一般的にTCPによって使用されます。このドキュメントは、他の上位層プロトコルにより発生した問題を処理しようとしません。 IPv6のパスMTUディスカバリ[RFC1981]は、IPv6のみに依存する問題を扱いますが、TCPの問題は、この文書で育っていません。

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.

問題の問題に関連した名前です。このメモでは、名前は、サブセクションの見出しとして与えられています。

Classification One or more problem categories for which the problem is classified: "congestion control", "performance", "reliability", "non-interoperation -- connectivity failure".

問題が分類された分類の一つまたは複数の問題カテゴリ：「輻輳制御」、「パフォーマンス」、「信頼性」、「非相互運用 - 接続障害」。

Description A definition of the problem, succinct but including necessary background material.

説明に必要な背景素材を含む簡潔問題の定義、しかし。

Significance A brief summary of the sorts of environments for which the problem is significant.

意義の問題が重要であるために環境の種類の簡単な要約。

Implications Why the problem is viewed as a problem.

問題が問題視されるのはなぜな意味。

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.

関連のRFC RFCは、問題が競合しているとTCPの仕様を定義します。これらのRFCは、多くの場合、このようなMUST、SHOULD、MAY、および大文字で書かれた他の人のような用語を使用して動作を修飾します。これらの用語の正確な解釈については、RFC 2119を参照してください。

Trace file demonstrating the problem One or more ASCII trace files demonstrating the problem, if applicable.

該当する場合、問題を実証する問題の一つまたは複数のASCIIトレースファイルを実演するトレースファイル。

Trace file demonstrating correct behavior One or more examples of how correct behavior appears in a trace, if applicable.

正しい動作に該当する場合、トレースにどのように表示されるか、正しい行動の1つの以上の例を実証したファイルをトレースします。

References References that further discuss the problem.

さらに問題を議論参照参照。

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 to fix For known causes of the problem, how to correct the implementation.

実装を修正するためにどのような問題の既知の原因については、修正する方法。

2. Known implementation problems

2.既知の実装上の問題

2.1. ２。１。

Name of Problem Black Hole Detection

問題ブラックホール検出の名前

Classification Non-interoperation -- connectivity failure

分類非相互運用 - 接続障害

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.

説明ホストがないフラグメント（DF）は、IPヘッダに設定されたビットが、できるだけ大きなパケットを送信することによって、パスMTU探索を行います。送信元アドレスに断片化必要メッセージ - パケットが特定のリンクへ転送するルータに対して大きすぎる場合、ルータはICMP宛先到達不能を送信する必要があります。ホストは、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メッセージを抑制するために間違って設定されています。実装は、適切な文書でアドバイスに従う場合の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メッセージが発信元ホストによって受信されない場合PMTUDは、[RFC1191]に記載されているように、障害が発生しました。上位層プロトコルは、ICMPメッセージなしで、大規模なパケットを送信し、しようとし続け、それはそれらのパケットのサイズを小さくする必要があることを発見することはありません。そのパケットは、PMTUDブラックホールに消えています。

Significance When PMTUD fails due to the lack of ICMP messages, TCP will also completely fail under some conditions.

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.

意味合いこの失敗は、pingを実行し、宛先ホストの仕事にいくつかのインタラクティブな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 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のないすなわちそれら）には影響しないパスを介して相互運用性の障害を受けるために、いくつかのTCP実装には不適切と思われます。これは、PMTUDを有効にしてTCPの実装を展開するため、市場の阻害要因を作成します。

Relevant RFCs RFC 1191 describes Path MTU Discovery. RFC 1435 provides an early description of these sorts of problems.

関連のRFCのRFC 1191は、パスMTUディスカバリを説明しています。 RFC 1435は、これらの種類の問題を早期に説明します。

Trace file demonstrating the problem Made using tcpdump [Jacobson89] recording at an intermediate host.

中間宿主での記録[Jacobson89]のtcpdumpを使用して作られた問題を実演するトレースファイル。

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 A> B：S 1748427200：1748427200（0）勝つ49152 <MSS 1460> 20：12：11.951829 B> A：S 1001927984：1001927984（0）ACK 1748427201勝つ16384 <MSS 65240>午前20時12分： 11.955230 A> B：。 12：11.959099 A> B ACK 1（DF）20 49152を獲得：。 1：12：13.139074 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：12：16.188685 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：12：22.290483 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：12：34.491856 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：12：58.896405 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：13：47.703184 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：14：52.780640 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：15：57.856037 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：17：02.932431 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：18：08.009337 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：19：13.090521 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：20：18.168066 A> B 1461（1460）ACK 1（DF）20 49152を獲得します：。 1：21：1461（1460）ACK 1（DF）20 49152を獲得23.242761 Aは> B：R 1461：1461（0）ACK 1（DF）を49152に勝ちます

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.

大きなデータパケットがネットワークを通過することはできません。最終的には、接続がタイムアウトします。その後、アプリケーションが失敗し、多くの大量の書き込み、のフォローアップ、成功した非常に小さな書き込み、と出て起動したとき、これは特に混乱することができます。

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 A> B：Sの271394446：48：271394446（0）8192 <MSS 1460>（DF）16を獲得42.672279 Bは> A：S 2837734676：2837734676（0）ACK 271394447 16384 <MSS 65240>を獲得

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 A> B：。 48：42.870574 A> B ACK 1（DF）16を8760に勝ちます：。 1：48：1461（1460）ACK 1は、8760（DF）16を獲得42.871799 A> Bを：。 1461：48：45.786814 A> B 2921（1460）ACK 1（DF）16を8760に勝ちます：。 1：48：1461（1460）ACK 1は、8760（DF）16を獲得51.794676 A> Bを：。 1：49：1461（1460）ACK 1は、8760（DF）16を獲得03.808912 A> Bを：。 1：537（536）、ACK 1勝8760 16：49：04.016476 B> A：。 49：537 16 16384に勝つackを04.021245 A> B：。 1073（536）、ACK 1勝8760 16：537 49：04.021697 A> B：。 1073：1609（536）、ACK 1勝8760 16：49：04.120694 B> A：。 49：：1609年16 16384に勝つackを04.126142 A> B：。 1609：2145（536）ACK 1 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メーリングリストで広く議論されてきました。名前「ブラックホール」は、長年にわたって使用されてきました。

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.

これを検出する方法タイムアウトによってクローズされるまで（これは多くの場合、接続して転送を開始、接続として現れ、そして最終的にはゼロバイトで転送して15分後に終了）（進捗状況を作るために失敗した）ハングTCPコネクションとして表示されます。これは、制御情報の小さなパケットを使用しながら、完全に動作し、その後バルク転送に失敗し、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を行うには、問題を示すことができ、いくつかのtracerouteの実装があります。

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を修正する方法の接続がタイムアウトしていることに気づくはずです。いくつかのタイムアウトの後、TCPは、おそらく各パケットのDFフラグをオフにし、小さなパケットを送信しようとしなければなりません。これが成功すれば、それはパスが変更されているかどうかを判断しようとするために、再度精査すべき後、時間のいくつかの合理的な期間のための接続のためにPMTUDをオフにし続けなければなりません。

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サポート最小IPv4の68オクテットの最小値よりも著しく大きい1280オクテットです。 IPv6のTCP実装は、IPv4の実装はおそらくブラックホールの検出に応答するDFをオフにする必要があります1280のオクテットのパケットにフォールバックするためにこれは、より合理的にする必要があります。

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. ２。２。

Name of Problem Stretch ACK due to PMTUD

問題ストレッチACKの名前によるPMTUDへ

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装備スタックと通信するとき、それは毎秒フルサイズセグメントの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.

ストレッチACKはより完全に[RFC2525]に概説され、不幸な種々の効果を有します。これらのほとんどが原因ACKのまれ到着に、より多くのバースト性の接続を促すこととしなければなりません。彼らはまた、輻輳ウィンドウの成長を妨げることができます。

Implications

含意

The complete implications of stretch ACKs are outlined in [RFC2525].

ストレッチACKの完全な意味は、[RFC2525]に概説されています。

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.

関連のRFCのRFC 1122は、ACKの発生頻度のための要件の概要を説明します。 [RFC2581]はこれとACKがないMUSTべきである遅延明確化に拡張します。

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の記録を使用して作られました。すべてが、最初の二つのパケットからタイムスタンプオプションを明確にするため削除されました。

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のA> B：S 3183102292：3183102292（0）勝つ16384 <MSS 4312、NOP、wscale 0、NOP、NOP、タイムスタンプ12128 0>（DF）18：16：52.979580 B> A：S 2022212745： 2022212745（0）ACK 3183102293 49152勝つ<MSS 4312、NOP、wscale 1、NOP、NOP、タイムスタンプ1592957 12128>（DF）18：16：52.979738 A> B：。 16：52.982473 A> B ACK 1（DF）18 17248を獲得：。 1：16：4301（4300）ACK 1（DF）18 17248を獲得52.982557 C> A：ICMP：B到達不能 - FRAG（MTU 1500）する必要があります！（DF）18：16：52.985839 B> A：。 16：54.129928 A> B ACK 1（DF）18 32768を獲得：。 1：1449（1448）ACK 1は、17248（DF）が勝利します。。。 18：16：58.507078 A> B：。 1463941：1465389（1448）ACK 1（DF）18 17248を獲得：16：58.507200 A> B：。 1465389：1466837（1448）ACK 1（DF）18 17248を獲得：16：58.507326 A> B：。 1466837：1468285（1448）ACK 1（DF）18 17248を獲得：16：58.507439 A> B：。 1468285：1469733（1448）ACK 1（DF）18 17248を獲得：16：58.524763 B> A：。 16：ACK 1452357は、18（DF）を32768に勝つ58.524986 B> A：。 16：確認応答1461045は（DF）18 32768を獲得58.525138 A> B：。 1469733：1471181（1448）ACK 1（DF）18 17248を獲得：16：58.525268 A> B：。 1471181：1472629（1448）ACK 1（DF）18 17248を獲得：16：58.525393 A> B：。 1472629：1474077（1448）ACK 1（DF）18 17248を獲得：16：58.525516 A> B：。 1474077：1475525（1448）ACK 1（DF）18 17248を獲得：16：58.525642 A> B：。 1475525：1476973（1448）ACK 1（DF）18 17248を獲得：16：58.525766 A> B：。 1476973：1478421（1448）ACK 1（DF）18 17248を獲得：16：58.526063 A> B：。 1478421：1479869（1448）ACK 1（DF）18 17248を獲得：16：58.526187 A> B：。 1479869：1481317（1448）ACK 1（DF）18 17248を獲得：16：58.526310 A> B：。 1481317：1482765（1448）ACK 1（DF）18 17248を獲得：16：58.526432 A> B：。 1482765：1484213（1448）ACK 1（DF）18 17248を獲得：16：58.526561 A> B：。 1484213：1485661（1448）ACK 1（DF）18 17248を獲得：16：58.526671 A> B：。 1485661：1487109（1448）ACK 1（DF）18 17248を獲得：16：58.537944 B> A：。 16：確認応答1478421は（DF）18 32768を獲得58.538328 A> B：。 1487109：1488557（1448）ACK 1勝つ17248（DF）

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.

ACKの間の間隔の2倍セグメントサイズよりもかなり大きいことに留意されたいです。それはほぼ正確に2回広告を出してMSSになるように動作します。この転送は、ストレッチ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.

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のA> B：S 2972697496：2972697496（0）勝つ16384 <MSS 4312、NOP、wscale 0、NOP、NOP、タイムスタンプ11326 0>（DF）18：13：32.290785 B> A：Sの245639054： 13：32.290941のA> B 245639054（0）ACK 2972697497 34496 <MSS 4312>（DF）18を獲得：。 13：32.293774 A> B ACK 1（DF）18 17248を獲得：。 1：13：4313（4312）ACK 1（DF）18 17248を獲得32.293856 C> A：ICMP：B到達不能 - FRAG（MTU 1500）する必要があります！（DF）18：13：33.637338 A> B：。 1：1461（1460）ACK 1は、17248（DF）が勝利します。。。 18：13：35.561691 A> B：。 1514021：1515481（1460）ACK 1（DF）18 17248を獲得：13：35.561814 A> B：。 1515481：1516941（1460）ACK 1（DF）18 17248を獲得：13：35.561938 A> B：。 1516941：1518401（1460）ACK 1（DF）18 17248を獲得：13：35.562059 A> B：。 1518401：1519861（1460）ACK 1（DF）18 17248を獲得：13：35.562174 A> B：。 1519861：1521321（1460）ACK 1（DF）18 17248を獲得：13：35.564008 B> A：。 13：確認応答1481901は（DF）18 64680を獲得35.564383 A> B：。 1521321：1522781（1460）ACK 1（DF）18 17248を獲得：13：35.564499 A> B：。 1522781：1524241（1460）ACK 1（DF）18 17248を獲得：13：35.615576 B> A：。 13：ACK 1484821は、18（DF）を64680に勝つ35.615646 B> A：。 13：ACK 1487741は、18（DF）を64680に勝つ35.615716 B> A：。 13：ACK 1490661は、18（DF）を64680に勝つ35.615784 B> A：。 13：ACK 1493581は、18（DF）を64680に勝つ35.615856 B> A：。 13：確認応答1496501は（DF）18 64680を獲得35.615952 A> B：。 1524241：1525701（1460）ACK 1（DF）18 17248を獲得：13：35.615966 B> A：。 13：確認応答1499421は（DF）18 64680を獲得35.616088 A> B：。 1525701：1527161（1460）ACK 1（DF）18 17248を獲得：13：35.616105 B> A：。 13：確認応答1502341は（DF）18 64680を獲得35.616211 A> B：。 1527161：1528621（1460）ACK 1（DF）18 17248を獲得：13：35.616228 B> A：。 13：確認応答1505261は（DF）18 64680を獲得35.616327 A> B：。 1528621：1530081（1460）ACK 1（DF）18 17248を獲得：13：35.616349 B> A：。 13：確認応答1508181は（DF）18 64680を獲得35.616448 A> B：。 1530081：1531541（1460）ACK 1（DF）18 17248を獲得：13：35.616565 A> B：。 1531541：1533001（1460）ACK 1（DF）18 17248を獲得：13：35.616891 A> B：。 1533001：1534461（1460）ACK 1勝つ17248（DF）

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よりも有意に大きいときにどのようにこの状態を検出するためには、パケットトレースで観察することができます。

How to fix Several solutions for this problem have been proposed:

この問題のいくつかの解決策を修正する方法が提案されています。

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にあります。これは非常に小さいパケットのたくさんの顔にACKの多数を生成するという欠点を有します。これは、X Window Systemなどのアプリケーションで表示されます。

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. ２。３。

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ではないかもしれない。）いくつかのシステムは、PMTUDをアドバタイズするMSSを決定する値を決定します。

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は、[RFC879]受信できる最大TCPセグメント約リモートシステムへの指示です。この値が小さすぎると、リモート・システムは、ローカルシステムが以前の特定のPMTUを発見純粋ので、送信時より小さなセグメントサイズを使用することを余儀なくされるであろう。

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.

関連のRFCのRFCは1191 [RFC879] MSS計算し、適切な値の完全な説明を提供します。この練習はこれらのRFCで仕様のいずれにも違反していないことに注意してください。

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.

このトレースは、中間ホスト上で実行されているのtcpdumpを使用して作られたことを証明するファイルをトレースします。ホストAは、B、ルータCはMTUボトルネックの場所でホストするために、A1とA2、二つの別個の連続接続を開始します。いつものように、TCPオプションは、すべての非SYNパケットから削除されます。

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.305912 A1> B：S 1523306220：1523306220（0）勝つ8760 <MSS 1460>（DF）22：33：32.306518 B> A1：Sの729966260：729966260（0）ACK 1523306221勝つ16384 <MSS 65240> 22 ：33：32.310307 A1> B：。 FRAGする必要があります（ - 129.99.238.5到達不能：33：32.323496 A1> B：P 1：1461（1460）ACK 1勝つ8760（DF）22：33：32.323569 C> A1：ICMP 8760（DF）22 1が勝つackをMTU 1024）（DF）（TTL 255、ID 20666）22：33：32.783694 A1> B：。 1：33：985（984）、ACK 1が8856（DF）22を獲得32.840817 B> A1を：。 33：：ackを985 16384 22に勝つ32.845651 A1> Bを：。 1461：33：2445（984）、ACK 1は、8856（DF）22を獲得32.846094 B> A1を：。 33：：ackを985 16384 22に勝つ33.724392 A1> Bを：。 985：1969（984）、ACK 1勝8856（DF）22：33：33.724893 B> A1：。 33：ACK 2445 14924 22に勝つ33.728591 A1> Bを：。 2445：33：2921（476）、ACK 1は、8856（DF）22を獲得33.729161 A1> Bが：。 33：33.840758 B> A1 1勝8856（DF）22がACKの場合：。 2921 ACK 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.238659 A1> B：F 7301：8193（892）、ACK 1勝8856（DF）22：33：34.239036 B> A1：。 8194勝つackを15492 22：33：34.239303 B> A1：F 1：1（0）8194にACK勝つ16384

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.242971 A1> B：。 ACK 2 8856（DF）22勝利：33：34.454218 A2は> B：S 1523591299：33：34.454617 B> A2：Sの732408874：732408874（0）ACK 1523591300 1523591299（0）8856 <MSS 984>（DF）22に勝ちます33：34.457516 A2> B 16384 <MSS 65240> 22勝ちます：。 33：34.470683 A2> B：P 1：985（984）、ACK 1勝8856（DF）22：33：34.471144 B> A2：ACK 1（DF）22を8856に勝ちます。 33：：ackを985 16384 22に勝つ34.476554 A2> Bを：。 985：1969（984）、ACK 1勝つ8856（DF）22：33：34.477580 A2> B：P 1969：2953（984）、ACK 1 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は、B、ルータCはMTUボトルネックの場所でホストするために、A1とA2、二つの別個の連続接続を開始します。いつものように、TCPオプションは、すべての非SYNパケットから削除されます。

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.828602 A1> B：S 3402991286：3402991286（0）勝つ32768 <MSS 4312、wscale 0、NOP、タイムスタンプ1123370309 0、エコー1123370309>（DF）22：36：58.844040 B> A1：Sの946999880：946999880 （0）ACK 3402991287勝つ16384 <MSS 65240、NOP、wscale 0、NOP、NOP、タイムスタンプ429552 1123370309> 22：36：58.848058 A1> B：。 36：58.851514 A1> B：P 1：36：1025（1024）ACK 1（DF）22 32768を獲得58.851584 C> A1：ICMP： - FRAGする必要があります（129.99.238.5到達不能ACK 1 22（DF）32768に勝ちますMTU 1024）（DF）22：36：58.855885 A1> B：。 1：36：58.856378 A1> B 969（968）、ACK 1 32768（DF）22を獲得：。 969：36：985（16）ACK 1（DF）22 32768を獲得59.036309 B> A1：。 36：59.039255 A1> B：FP 985：16384 22に勝つ985を確認応答36：1025（40）ACK 1（DF）22 32768を獲得59.039623 B> A1を：。 1026は勝つackを16344 22：36：59.039828 B> A1：F 1：1（0）1026にACK 16384 22勝利：36：59.043037 A1> Bが：。図2は、32768（DF）を勝つackを22：37：01.436032 A2> B：S 3404812097：3404812097（0）勝つ32768 <MSS 4312、wscale 0、NOP、タイムスタンプ1123372916 0、エコー1123372916>（DF）22：37：01.436424 B > A2：Sは、949814769：949814769（0）ACK 3404812098勝つ16384 <MSS 65240、NOP、wscale 0、NOP、NOP、タイムスタンプ429562 1123372916> 22：37：01.440147 A2> B：。 37：01.442736 A2> B ACK 1（DF）22 32768を獲得：。 1：969（968）ACK 1勝つ32768（DF）

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.442894 A2> B：P 969：37：985（16）ACK 1は22 32768（DF）を勝つ01.443283のB> A2：。 37：985 22 16384を獲得確認応答01.446068 A2> B：P 985：1025（40）ACK 1 32768（DF）を勝つ22：37：01.446519のB> A2：。 37：ACK 1025 16384 22に勝つ01.448465 A2> B：F 1025：37：1025（0）ACK 1（DF）22 32768を獲得01.448837 B> A2：。 1026は勝つackを16384 22：37：01.449007 B> A2：F 1：1（0）1026にACK 16384 22勝利：37：01.452201 A2> Bが：。 2は32768に勝つACK（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つの別々の接続のパケットトレースを使用して検出することができます。最初は、PMTUDを呼び出す必要があります。第二は、PMTU値がタイムアウトしないことを最初にした後、すぐに十分な開始すべきです。

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の修正方法[RFC1122]及び[RFC1191]に概説するように、システム上のインターフェースのMTUのに基づいて決定されるべきです。

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.

このメモで提起つのセキュリティ上の懸念は、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.

初期のPMTUDブラックホールが発生する可能性がありますさまざまなメカニズムの提案だけでなく、レビューのために文書をレビュー寛大な助けのためのマーク・オールマン、バーン・パクソン、およびジャムシードMahdaviのおかげで、マット・マティスへ。 TCPの問題点を説明するための構造、及びその構造の初期の説明は[RFC2525]です。これらのバグを発見したPMTUDテストを行う助けたエイミー・ボック、に感謝します。

5. References

5.参考文献

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

[RFC2581]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。

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

[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。

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

[RFC813]クラーク、D.、 "TCPでウィンドウと謝辞戦略"、RFC 813、1982年7月。

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

【Jacobson89】V. Jacobsonの、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アドバイス"、RFC 1435、1993年3月。

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

[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、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.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、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.パクソン、 "インターネットにおけるエンド・ツー・エンドのルーティング動作"、ネットワーク上のIEEE / ACM取引（5）、頁〜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実装の問題」、RFC 2525、1999年3月。

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

[RFC879]ポステル、J.、 "TCP最大セグメントサイズと関連項目"、RFC 879、1983年11月。

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

[RFC2001]スティーブンス、W.、 "TCPスロースタート、輻輳回避、高速再送、および高速リカバリアルゴリズム"、RFC 2001、1997年1月。

6. Author's Address

6.著者のアドレス

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

ケビン・レイヒーdotRocket、Inc.の1901 S. BASCOMアベニュー、スイート300キャンベル、CA 95008 USA

Phone: +1 408-371-8977 x115 email: kml@dotrocket.com

電話：+1 408-371-8977 x115メール：kml@dotrocket.com

7. Full Copyright Statement

7.完全な著作権声明

著作権（C）インターネット協会（2000）。全著作権所有。

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.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。