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

原文URL : https://datatracker.ietf.org/doc/html/rfc2923
タイトル : RFC 2923 - PATH MTU発見に関するTCPの問題
翻訳編集 : 自動生成

[要約] 要約：RFC 2923は、TCPのパスMTU探索に関する問題を解決するためのガイドラインを提供しています。目的：このRFCの目的は、パスMTU探索の問題を理解し、TCPのパフォーマンスと信頼性を向上させるためのソリューションを提供することです。

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

TCP Problems with Path MTU Discovery

PATH 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.

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

著作権表示

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.

このメモは、長年のブラックホール問題、最大セグメントサイズ（MSS）とセグメントの混乱によるストレッチ謝辞（ACK）を含む、パス最大伝送ユニット発見（PMTUD）を扱ういくつかの既知の伝送制御プロトコル（TCP）の実装問題をカタログ化します。サイズ、および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.

このメモは、長年のブラックホールの問題、MSSとセグメントサイズの混乱によるストレッチAcks、PMTUに基づくMSS広告など、Path 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.

Path MTU Discovery（PMTUD）は、上層層プロトコルで使用できますが、TCPで最も一般的に使用されます。このドキュメントは、他の上層層プロトコルで遭遇した問題を治療しようとはしません。IPv6 [RFC1981]のPATH MTUディスカバリーは、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".

分類問題が分類される1つ以上の問題カテゴリ：「混雑制御」、「パフォーマンス」、「信頼性」、「非侵入 - 接続障害」。

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は、問題が矛盾するTCP仕様を定義するRFCを関連付けます。これらのRFCは、しばしば、Must、Suff、May、およびその他の書面による用語を使用して動作を修飾します。これらの用語の正確な解釈については、RFC 2119を参照してください。

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

問題を示すトレースファイル1つ以上の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.

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ヘッダーに設定されていないDONTフラグメント（DF）ビットを使用して、できるだけ大きなパケットを送信することにより、PATH 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.

重要性ICMPメッセージが不足しているためPMTUDが失敗した場合、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.

意味この障害は、ピングと宛先ホスト作業へのインタラクティブな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実装が、他のTCP実装（つまり、PMTUDのないもの）に影響を与えないパス上で相互運用性の障害を被ることは不適切と思われます。これにより、PMTUDが有効になってTCP実装を展開するための市場が妨げられます。

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

関連するRFCS RFC 1191は、パスMTU発見について説明しています。RFC 1435は、これらの種類の問題の初期の説明を提供します。

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.

これを検出する方法は、タイムアウトで閉じられるまでハングする（進行に失敗する）TCP接続として表示されます（これは、接続して転送を開始する接続として現れ、最終的にはゼロバイトを転送して15分後に終了します）。これは、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は1280オクテットで、IPv4の68オクテットの最小値よりも大幅に大きいです。これにより、IPv6 TCPの実装が1280 Octetパケットに戻ることがより合理的になります。これにより、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による問題の名前ストレッチ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.

説明NYIVELY実装されたTCPスタックがPMTUD装備のスタックと通信すると、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.

ストレッチアックにはさまざまな不幸な効果があり、[RFC2525]でより完全に概説されています。これらのほとんどは、ACKのまれな到着のために、より爆発的なつながりを促進することに関係しています。また、混雑の窓の成長を妨げる可能性があります。

Implications

意味

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

ストレッチアックの完全な意味は、[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.

関連するRFCS RFC 1122は、ACK生成の頻度の要件の概要を示しています。[RFC2581]はこれを拡張し、遅延したACKが必須ではないことを明確にします。

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.

18：16：52.976657 A> B：S 3183102292：3183102292（0）Win 16384 <MSS 4312、NOP、WSCALE 0、NOP、NOP、タイムスタンプ0>（DF）18：16：52.979580 B>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耐えられない-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）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.

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.)

18：13：32.287965 A> B：S 2972697496：2972697496（0）Win 16384 <MSS 4312、NOP、WSCALE 0、NOP、NOP、TIMESTAMP11326 0>（DF）18：13：32.290785 B> A：290785 B>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耐えられない-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）このトレースでは、到着した2つのセグメントごとにACKが生成されます。（このトレースでは、このトレースが同じであるにもかかわらず、このトレースではセグメントのサイズがわずかに大きくなります。

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.

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の重要性は、受信できる最大の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]を考えると、リターン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計算と適切な値の完全な議論を提供します。このプラクティスは、これらの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を開始してBをホストします。ルーターCはMTUボトルネックの位置です。いつものように、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: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を開始してBをホストします。ルーターCはMTUボトルネックの位置です。いつものように、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: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.

セッションA1とセッションA2の両方に同じMSSが使用されたことに注意してください。

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].

[RFC1122]および[RFC1191]で概説されているように、システム上のインターフェイスのMTUに基づいてMSSを修正する方法を決定する必要があります。

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実装がデータからデータを転送できない場合、世界で最も安全なWebサイトは価値がありません。すべての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、およびPMTUDブラックホールを引き起こす可能性のあるさまざまなメカニズムの初期の提案については、Matt Mathisに感謝します。TCPの問題を説明するための構造、およびその構造の初期の説明は[RFC2525]からのものです。これらのバグを発見したPMTUDテストの実行を手伝ったエイミーボックに感謝します。

5. References

5. 参考文献

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

[RFC2581] Allman、M.、Paxson、V。and W. Stevens、「TCP混雑制御」、RFC 2581、1999年4月。

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

[RFC1122] Braden、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] Knowles、S。、「Path MTU Discoveryの経験からのIESGアドバイス」、RFC 1435、1993年3月。

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

[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。

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

[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、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. Paxson、「インターネットでのエンドツーエンドのルーティング動作」、IEEE/ACMトランザクションに関するトランザクション（5）、pp。〜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.、Allman、M.、Dawson、S.、Fenner、W.、Griner、J.、Heavens、I.、Lahey、K.、Semke、I.およびB. Volz、 "既知のTCP実装の問題」、RFC 2525、1999年3月。

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

[RFC879] Postel、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] Stevens、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

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. 完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。