この文書はRFC2923の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group K. Lahey Request for Comments: 2923 dotRocket, Inc. Category: Informational September 2000 TCP Problems with Path MTU Discovery パスMTU探索におけるTCP問題 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. このメモはインターネット共同体のための情報を供給します。これはインター ネット標準を指定しません。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (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. このメモはいくつかの既知の伝送制御プロトコル(TCP)実装問題の一覧を示 します、これは長期存続ブラックホール問題を含むパス最大限伝送単位探索 (PMTUD)と、最大セグメントサイズとセグメントサイズの混乱による肯定応 答(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. します、これは長期存続ブラックホール問題を含むパスMTU探索[RFC1191] と、最大セグメントサイズとセグメントサイズの混乱によるACK遅延と、 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. パス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 適切なRFC 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仕様を定義しているRFC 。これらのRFCはしばしば MUST、SHOULD、MAYやその他の大文字化で書かれた用語を使っている行動 を制限します。これらの用語の正確な解釈のためにRFC2119を見てくださ い。 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. 可能なら、トレース正しい行動の例。 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. ホストが、IPヘッダーでのフラグメント禁止(DF)ビットを設定し、可 能な限り大きいパケットを送ることによってパス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-in-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. [RFC1191]で文書化されるようにPMTUDは、適切なICMPメッセー ジが出発点のホストに届かないと失敗します。上位レイヤプロトコルは 大きいパケットを送ろうとし続けて、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 RFC 1191 describes Path MTU Discovery. RFC 1435 provides an early description of these sorts of problems. RFC1191はパスMTU探索を記述します。RFC1435がこれらの問題の種類の 初期の記述を供給します。 Trace file demonstrating the problem 問題を実演するトレースファイル Made using tcpdump [Jacobson89] recording at an intermediate host. 中間ホストでのtcpdump[Jacobson89]を使って記録。 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) 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.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 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分間0バ イトしか送れない事として表れます)で接続が終わるまで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. 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. TCPが接続がタイムアウトしていることに気付くべきです。いくつかの タイムアウトの後に、TCPが多分DFフラグをオフにして、より小さい サイズのパケットを送ろうと試みるべきです。もしこれが成功するなら、 それは合理的な一定期間この接続のPMTUDをオフにし続けるべきで、 その後でパスが変わったかどうか再び検査するべきです。IPv6下でD Fビットがないことに注意して下さい−これはいつも暗黙のうちに実行さ れます。分割はルーターで行うことが許されず、出発点のホストでだけ許 されません。幸いにIPv6の最小サポートMTUは1280オクテット で、これはIPv4の68オクテットよりかなり大きいです。IPv4実 装がブラックホール検出に対しておそらくDFをオフにするが、IPv6 TCP実装が1280のオクテットパケットに後退することを合理的で しょう。 Ideally, the ICMP black holes should be fixed when they are found. 理想的にはUCMPブラックホールは見つけ次第修理されるべきです。 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 PMTUDのために広がった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を装備したスタックと通信 する時、それはすべての2番目の最大サイズセグメントでACKを生成し ようとするでしょう。もし素朴なTCPスタックが広告された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 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. RFC1122はACK生成頻度の必要条件を概説します。[RFC2581]がこれを詳 細に述べ、遅延ACKがMUSTではなく、SHOULDであることを明確にします。 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) 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倍より大きいことに注意してくだ さい;これはほとんど正確に広告された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) 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ウィンドウシステムのようなアプリケーションで 現われます。 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で決定した値を広告するMMSに使います。 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を見つけた場合、 もしこの値があまりにも小さいならリモートシステムは送信する時により小 さいセグメントサイズを強いられるでしょう。 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]帰りのPM TUが送信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は2つの 平行した連続接続A1とA2をを行います。ルーターCはMTUボトルネッ クの場所です。いつものように、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: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.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. セッション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をを行います。ルーターCは MTUボトルネックの場所です。いつものように、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: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. 同じ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を呼び出すべきです;第2は最初の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メッセージを妨げる熱心過ぎるセキュリティ管理者に よって起こされるということです。セキュリティシステムを設計して、配置 する人たちが厳密なフィルターの上位レイヤプロトコルへの影響を理解する ことは非常に重要です。世界中の最も安全なWebサイトであっても、もし ほとんどの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. Mark AllmanとVern PaxsonとJamshid Mahdaviの文書のレビューに、 Matt MathisのPMTUDブラックホールの原因の様々なメカニズムの初期 の考察とレビューに感謝します。TCP問題とその構造の初期の記述の構造 は[RFC2525]からです。PMTUDテストの実施の手助けとバグの発見につ いてAmy Bockへ特別な感謝をします。 5. References 5. 参考文献 [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. 6. Author's Address 6. 著者のアドレス Kevin Lahey dotRocket, Inc. 1901 S. Bascom Ave., Suite 300 Campbell, CA 95008 USA Phone: +1 408-371-8977 x115 email: kml@dotrocket.com 7. Full Copyright Statement 7. 著作権表示全文 Copyright (C) The Internet Society (2000). All Rights Reserved. 著作権(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エディタ機能のための資金供給が現在インターネット学会によって 供給されます。