[要約] RFC 5461は、TCPがソフトエラーに対してどのように反応するかについてのガイドラインです。その目的は、ネットワークの信頼性を向上させ、パフォーマンスの低下を最小限に抑えることです。
Network Working Group F. Gont
Request for Comments: 5461 UTN/FRH
Category: Informational February 2009
TCP's Reaction to Soft Errors
ソフトエラーに対する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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments.
このドキュメントでは、非標準的な、しかし広く実装された変更、TCPのICMPソフトエラーメッセージの処理に対する変更について説明します。この動作は、デフォルトで有効になっているデュアルスタックノードがIPv4またはIPv4およびIPv6環境の混合で展開されるデュアルスタックノードを含む、多くのシナリオを含む、多くのシナリオを含む、多くのシナリオで発生する可能性のある接続確立の試みの間の長い遅延の可能性を減らします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Error Handling in TCP . . . . . . . . . . . . . . . . . . . . 3
2.1. Reaction to ICMP Error Messages That Indicate Hard
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Reaction to ICMP Error Messages That Indicate Soft
Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problems That May Arise from TCP's Reaction to Soft Errors . . 5
3.1. General Discussion . . . . . . . . . . . . . . . . . . . . 5
3.2. Problems That May Arise with Dual-Stack IPv6 on by
Default . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployed Workarounds for Long Delays between
Connection-Establishment Attempts . . . . . . . . . . . . . . 7
4.1. Context-Sensitive ICMP/TCP Interaction . . . . . . . . . . 7
4.2. Context-Sensitive ICMP/TCP Interaction with Repeated
Confirmation . . . . . . . . . . . . . . . . . . . . . . . 8
5. Possible Drawbacks of Changing ICMP Semantics . . . . . . . . 9
5.1. Non-Deterministic Transient Network Failures . . . . . . . 9
5.2. Deterministic Transient Network Failures . . . . . . . . . 10
5.3. Non-Compliant Network Address Translators (NATs) . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
The handling of network failures can be separated into two different actions: fault isolation and fault recovery. Fault isolation consists of the actions that hosts and routers take to determine that there is a network failure. Fault recovery, on the other hand, consists of the actions that hosts and routers perform in an attempt to survive a network failure [RFC0816].
ネットワーク障害の処理は、障害分離と障害回復の2つの異なるアクションに分離できます。障害分離は、ホストとルーターがネットワークの障害があることを判断するために取るアクションで構成されています。一方、障害回復は、ネットワークの障害に耐えようとする試みでホストとルーターを実行するアクションで構成されています[RFC0816]。
In the Internet architecture, the Internet Control Message Protocol (ICMP) [RFC0792] is one fault isolation technique to report network error conditions to the hosts sending datagrams over the network.
インターネットアーキテクチャでは、インターネット制御メッセージプロトコル（ICMP）[RFC0792]は、ネットワーク上でデータグラムを送信するホストにネットワークエラー条件を報告するための1つの障害分離手法です。
When a host is notified of a network error, its network stack will attempt to continue communications, if possible, in the presence of the network failure. The fault recovery strategy may depend on the type of network failure taking place and the time at which the error condition is detected.
ホストにネットワークエラーが通知されると、ネットワークスタックは、可能であれば、ネットワークの障害の存在下で通信を継続しようとします。障害回復戦略は、発生するネットワーク障害のタイプと、エラー条件が検出される時間に依存する場合があります。
This document analyzes the problems that may arise due to TCP's fault recovery reactions to ICMP soft errors. It analyzes the problems that may arise when a host tries to establish a TCP connection with a multihomed host that has some unreachable addresses. Additionally, it analyzes the problems that may arise in the specific scenario where dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments.
このドキュメントは、ICMPソフトエラーに対するTCPの障害回復反応により発生する可能性のある問題を分析します。ホストが、いくつかの到達不可能なアドレスを持つマルチホームホストとのTCP接続を確立しようとすると発生する可能性のある問題を分析します。さらに、デフォルトで有効になっているデュアルスタックノードがIPv4またはIPv4およびIPv6環境の混合で展開される特定のシナリオで発生する可能性のある問題を分析します。
Finally, we document a modification to TCP's reaction to ICMP messages indicating soft errors during connection startup that has been implemented in a variety of TCP/IP stacks to help overcome the problems outlined below. We stress that this modification runs contrary to the standard behavior and this document unambiguously does not change the standard reaction.
最後に、以下に概説する問題を克服するために、さまざまなTCP/IPスタックで実装された接続スタートアップ中にソフトエラーを示すICMPメッセージに対するTCPの反応の変更を文書化します。この変更は標準的な動作に反して実行され、この文書は標準反応を明確に変更しないことを強調します。
[Gont] describes alternative approaches for dealing with the problem of long delays between connection-establishment attempts in TCP.
[Gont]は、TCPの接続確立の試みの間の長い遅延の問題に対処するための代替アプローチについて説明しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
Network errors can be divided into soft and hard errors. Soft errors are considered to be transient network failures that are likely to be solved in the near term. Hard errors, on the other hand, are considered to reflect network error conditions that are unlikely to be solved in the near future.
ネットワークエラーは、ソフトエラーとハードエラーに分けることができます。ソフトエラーは、短期的に解決される可能性が高い一時的なネットワーク障害であると見なされます。一方、ハードエラーは、近い将来解決される可能性が低いネットワークエラー条件を反映すると見なされます。
The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that the ICMP messages that indicate soft errors are ICMP "Destination Unreachable" codes 0 (network unreachable), 1 (host unreachable), and 5 (source route failed); ICMP "Time Exceeded" codes 0 (time to live exceeded in transit) and 1 (fragment reassembly time exceeded); and ICMP "Parameter Problem". Even though ICMPv6 did not exist when [RFC1122] was written, one could extrapolate the concept of soft errors to ICMPv6 "Destination Unreachable" codes 0 (no route to destination) and 3 (address unreachable); ICMPv6 "Time Exceeded" codes 0 (hop limit exceeded in transit) and 1 (fragment reassembly time exceeded); and ICMPv6 "Parameter Problem" codes 0 (erroneous header field encountered), 1 (unrecognized Next Header type encountered), and 2 (unrecognized IPv6 option encountered) [RFC4443].
ホスト要件RFC [RFC1122]は、セクション4.2.3.9で、ソフトエラーを示すICMPメッセージは、ICMP「宛先の到達不可能」コード0（ネットワークの到達不能）、1（ホストの到達不能）、および5（ソースルートが失敗した）であると述べています。ICMP「時間を超えた」コード0（輸送中にライブを超える時間）および1（フラグメント再組み立て時間を超えた）。およびICMP「パラメーター問題」。[RFC1122]が書かれたときにICMPV6は存在しませんでしたが、ソフトエラーの概念をICMPV6「宛先の到達不可能な」コード0（宛先へのルートなし）および3（到達不可能なアドレス）に外挿することができます。ICMPv6「時間を超えた時間」コード0（輸送中のホップ制限が超えた）および1（フラグメント再組み立て時間が超えた）。およびICMPV6 "パラメーター問題"コード0（遭遇した誤ったヘッダーフィールド）、1（認識されていない次のヘッダータイプが遭遇した）、および2（認識されていないIPv6オプションが遭遇した）[RFC4443]。
+----------------------------------+--------------------------------+
| ICMP | ICMPv6 |
+----------------------------------+--------------------------------+
| Destination Unreachable (codes | Destination Unreachable (codes |
| 0, 1, and 5) | 0 and 3) |
+----------------------------------+--------------------------------+
| Time Exceeded (codes 0 and 1) | Time Exceeded (codes 0 and 1) |
+----------------------------------+--------------------------------+
| Parameter Problem | Parameter Problem (codes 0, 1, |
| | and 2) |
+----------------------------------+--------------------------------+
Table 1: Extrapolating the concept of soft errors to ICMPv6
表1：ソフトエラーの概念をICMPv6に推定する
When there is a network failure that is not signaled to the sending host, such as a gateway corrupting packets, TCP's fault recovery action is to repeatedly retransmit the corresponding data until either they get acknowledged or the connection times out.
ゲートウェイの破損パケットなど、送信ホストに通知されないネットワーク障害がある場合、TCPの障害回復アクションは、対応するデータが認められるか、接続時間が出るまで繰り返し再送信することです。
In the case that a host does receive an ICMP error message referring to an ongoing TCP connection, the IP layer will pass this message up to the corresponding TCP instance to raise awareness of the network failure [RFC1122]. TCP's reaction to ICMP messages will depend on the type of error being signaled.
ホストが進行中のTCP接続を参照するICMPエラーメッセージを受け取る場合、IPレイヤーはこのメッセージを対応するTCPインスタンスに渡して、ネットワーク障害の認識を高めます[RFC1122]。ICMPメッセージに対するTCPの反応は、通知されるエラーのタイプに依存します。
When receiving an ICMP error message that indicates a hard error condition, compliant TCP implementations will simply abort the corresponding connection, regardless of the connection state.
ハードエラー条件を示すICMPエラーメッセージを受信すると、接続されたTCP実装は、接続状態に関係なく、対応する接続を中止するだけです。
The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that TCP SHOULD abort connections when receiving ICMP error messages that indicate hard errors. This policy is based on the premise that, as hard errors indicate network error conditions that will not change in the near term, it will not be possible for TCP to usefully recover from this type of network failure.
ホスト要件RFC [RFC1122]は、セクション4.2.3.9に、ハードエラーを示すICMPエラーメッセージを受信するときにTCPが接続を中止する必要があると述べています。このポリシーは、硬いエラーが短期的には変化しないネットワークエラー条件を示しているため、TCPがこのタイプのネットワーク障害から有用に回復することは不可能であるという前提に基づいています。
It should be noted that virtually none of the current TCP implementations follow the advice in [RFC1122], and they do not abort the corresponding connection when an ICMP hard error is received for a connection that is in any of the synchronized states [ICMP-ATTACKS].
現在のTCP実装のいずれも[RFC1122]のアドバイスに従うことはほとんどなく、同期された状態のいずれかの接続に対してICMPハードエラーを受信した場合、対応する接続を中止しないことに注意する必要があります。]。
If an ICMP error message is received that indicates a soft error, TCP will repeatedly retransmit the corresponding data until either they get acknowledged or the connection times out. In addition, the TCP sender may record the information for possible later use (see [Stevens], pp. 317-319).
ソフトエラーを示すICMPエラーメッセージが受信された場合、TCPは、確認されるか、接続がタイムアウトするまで、対応するデータを繰り返し再送信します。さらに、TCP送信者は、後で使用できる可能性のある情報を記録する場合があります（[Stevens]、pp。317-319を参照）。
The Host Requirements RFC [RFC1122] states, in Section 4.2.3.9, that TCP MUST NOT abort connections when receiving ICMP error messages that indicate soft errors. This policy is based on the premise that, as soft errors are transient network failures that will hopefully be solved in the near term, one of the retransmissions will succeed.
ホスト要件RFC [RFC1122]は、セクション4.2.3.9に、ソフトエラーを示すICMPエラーメッセージを受信するときにTCPが接続を中止してはならないと述べています。このポリシーは、ソフトエラーが一時的なネットワーク障害であるため、短期的に解決されることを願っていますが、再送信の1つが成功するという前提に基づいています。
When the connection timer expires and an ICMP soft error message has been received before the timeout, TCP can use this information to provide the user with a more specific error message (see [Stevens], pp. 317-319).
接続タイマーの有効期限が切れ、タイムアウト前にICMPソフトエラーメッセージが受信された場合、TCPはこの情報を使用して、より具体的なエラーメッセージをユーザーに提供できます（[Stevens]、pp。317-319を参照）。
This reaction to soft errors exploits a valuable feature of the Internet -- that, for many network failures, the network can be dynamically reconstructed without any disruption of the endpoints.
ソフトエラーに対するこの反応は、インターネットの貴重な機能を活用します。これは、多くのネットワーク障害で、エンドポイントを混乱させることなくネットワークを動的に再構築できることです。
Even though TCP's fault recovery strategy in the presence of soft errors allows for TCP connections to survive transient network failures, there are scenarios in which this policy may cause undesirable effects.
ソフトエラーの存在下でのTCPの障害回復戦略により、TCP接続が過渡ネットワークの障害に耐えることができますが、このポリシーが望ましくない効果を引き起こすシナリオがあります。
For example, consider a scenario in which an application on a local host is trying to communicate with a destination whose name resolves to several IP addresses. The application on the local host will try to establish a connection with the destination host, usually cycling through the list of IP addresses until one succeeds [RFC1123]. Suppose that some (but not all) of the addresses in the returned list are permanently unreachable. If such a permanently unreachable address is the first in the list, the application will likely try to use it first and block waiting for a timeout before trying an alternate address.
たとえば、ローカルホストのアプリケーションが、名前がいくつかのIPアドレスに解決する目的地と通信しようとしているシナリオを検討してください。ローカルホストのアプリケーションは、宛先ホストとの接続を確立しようとします。通常、IPアドレスのリストを繰り返します[RFC1123]。返されたリストのアドレスの一部（すべてではありませんが）が永久に到達できないと仮定します。このような永続的に到達不可能なアドレスがリストの最初のアドレスである場合、アプリケーションは最初にそれを使用し、代替アドレスを試す前にタイムアウトを待っていることをブロックしようとする可能性があります。
As discussed in Section 2, this unreachability condition may or may not be signaled to the sending host. If the local TCP is not signaled concerning the error condition, there is very little that can be done other than to repeatedly retransmit the SYN segment and wait for the existing timeout mechanism in TCP, or an application timeout, to be triggered. However, even if unreachability is signaled by some intermediate router to the local TCP by means of an ICMP soft error message, the local TCP will still repeatedly retransmit the SYN segment until the connection timer expires (in the hopes that the error is transient). The Host Requirements RFC [RFC1122] states that this timer MUST be large enough to provide retransmission of the SYN segment for at least 3 minutes. This would mean that the application on the local host would spend several minutes for each unreachable address with which it tries to establish the TCP connection. These long delays between connection-establishment attempts would be inappropriate for many interactive applications, such as the Web. [Shneiderman] and [Thadani] offer some insight into interactive systems (e.g., how the response time affects the usability of an application). This highlights that there is no one definition of a "transient error" and that the level of persistence in the face of failure represents a tradeoff.
セクション2で説明したように、この到達不能条件は、送信ホストに通知される場合とそうでない場合があります。エラー条件に関してローカルTCPがシグナルになっていない場合、Synセグメントを繰り返し再送信し、TCPの既存のタイムアウトメカニズムまたはアプリケーションタイムアウトをトリガーする以外に実行できることはほとんどありません。ただし、ICMPソフトエラーメッセージによってローカルTCPへの中間ルーターによって到達不能が通知されたとしても、ローカルTCPは、接続タイマーが期限切れになるまでSynセグメントを繰り返し再送信します（エラーが過剰になることを期待して）。ホスト要件RFC [RFC1122]は、このタイマーが少なくとも3分間Synセグメントの再送信を提供するのに十分な大きさでなければならないと述べています。これは、ローカルホストのアプリケーションが、TCP接続を確立しようとする到達不可能なアドレスごとに数分を費やすことを意味します。接続確立の試みの間のこれらの長い遅延は、Webなどの多くのインタラクティブなアプリケーションにとって不適切です。[Shneiderman]と[Thadani]は、インタラクティブシステム（例えば、応答時間がアプリケーションの使いやすさにどのように影響するか）についての洞察を提供します。これは、「一時的なエラー」の定義はなく、障害に直面した持続性のレベルがトレードオフを表していることを強調しています。
It is worth noting that while most applications try the addresses returned by the name-to-address function in serial, this is certainly not the only possible approach. For example, applications could try multiple addresses in parallel until one succeeds, possibly avoiding the problem of long delays between connection-establishment attempts described in this document [Gont].
ほとんどのアプリケーションは、シリアルの名前からアドレスへの名前から返されるアドレスを試してみてくださいが、これが確かに唯一の可能なアプローチではないことに注意してください。たとえば、アプリケーションは、1つが成功するまで並行して複数のアドレスを試すことができ、おそらくこのドキュメント[GONT]で説明されている接続確立の試みの間の長い遅延の問題を回避する可能性があります。
A particular scenario in which the above type of problem may occur regularly is that where dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments and the IPv6 connectivity is non-existent [RFC4943].
上記のタイプの問題が定期的に発生する可能性のある特定のシナリオは、デフォルトで有効になっているデュアルスタックノードがIPv4またはIPv4およびIPv6環境で展開され、IPv6接続が存在しない[RFC4943]。
As discussed in [RFC4943], there are two possible variants of this scenario, which differ in whether or not the lack of connectivity is signaled to the sending node.
[RFC4943]で説明したように、このシナリオには2つの可能なバリエーションがあります。これは、送信ノードに接続性の欠如が通知されるかどうかが異なります。
In those scenarios in which packets sent to a destination are silently dropped and no ICMPv6 [RFC4443] errors are generated, there is little that can be done other than to wait for the existing connection-timeout mechanism in TCP, or an application timeout, to be triggered.
宛先に送信されたパケットが静かにドロップされ、ICMPv6 [RFC4443]エラーが生成されないシナリオでは、TCPの既存の接続タイムアウトメカニズム、またはアプリケーションタイムアウトを待つ以外にできることはほとんどありません。トリガーされます。
In scenarios where a legacy node has no default routers and Neighbor Unreachability Detection (NUD) [RFC4861] fails for destinations assumed to be on-link, or where firewalls or other systems that enforce scope boundaries send ICMPv6 errors, the sending node will be signaled of the unreachability problem. However, as discussed in Section 2.2, compliant TCP implementations will not abort connections when receiving ICMP error messages that indicate soft errors.
レガシーノードにデフォルトのルーターがないシナリオでは、近隣の到達不能検出（NUD）[RFC4861]は、オンリンクであると想定される宛先、またはスコープ境界を施行するファイアウォールまたはその他のシステムがICMPv6エラーを送信する場合、送信ノードは通知されます到達不能の問題の。ただし、セクション2.2で説明したように、準拠したTCP実装は、ソフトエラーを示すICMPエラーメッセージを受信した場合、接続を中止しません。
The following subsections describe a number of workarounds for the problem of long delays between connection-establishment attempts that have been implemented in a variety of TCP/IP stacks. We note that treating soft errors as hard errors during connection establishment, while widespread, is not part of standard TCP behavior and this document does not change that state of affairs. The consensus of the TCPM WG (TCP Maintenance and Minor Extensions Working Group) was to document this widespread implementation of nonstandard TCP behavior but to not change the TCP standard.
以下のサブセクションでは、さまざまなTCP/IPスタックで実装されている接続確立の試みの間の長い遅延の問題に関する多くの回避策について説明しています。接続の確立中にソフトエラーを硬いエラーとして扱うことは、標準的なTCP動作の一部ではなく、この文書はその状況を変えないことに注意してください。TCPM WG（TCPメンテナンスとマイナーエクステンションワーキンググループ）のコンセンサスは、非標準のTCP動作のこの広範な実装を文書化することでしたが、TCP標準を変更しないことでした。
As discussed in Section 1, it may make sense for the fault recovery action to depend not only on the type of error being reported but also on the state of the connection against which the error is reported. For example, one could infer that when an error arrives in response to opening a new connection, it is probably caused by opening the connection improperly, rather than by a transient network failure [RFC0816].
セクション1で説明したように、報告されるエラーの種類だけでなく、エラーが報告される接続の状態にも依存することは理にかなっているかもしれません。たとえば、新しい接続を開くことに応じてエラーが到来すると、過渡ネットワーク障害[RFC0816]ではなく、接続を不適切に開くことが原因であると推測できます。
A number of TCP implementations have modified their reaction to all ICMP soft errors and treat them as hard errors when they are received for connections in the SYN-SENT or SYN-RECEIVED states. For example, this workaround has been implemented in the Linux kernel since version 2.0.0 (released in 1996) [Linux]. However, it should be noted that this change violates section 4.2.3.9 of [RFC1122], which states that these ICMP error messages indicate soft error conditions and that, therefore, TCP MUST NOT abort the corresponding connection.
多くのTCP実装により、すべてのICMPソフトエラーに対する反応が変更され、Syn-SentまたはSyn-Received状態の接続に対して受信された場合、それらを硬いエラーとして扱います。たとえば、この回避策は、バージョン2.0.0（1996年にリリース）[Linux]以来、Linuxカーネルに実装されています。ただし、この変更は[RFC1122]のセクション4.2.3.9に違反していることに注意する必要があります。これは、これらのICMPエラーメッセージがソフトエラー条件を示し、したがって、TCPが対応する接続を中止してはならないと述べています。
[RFC3168] states that a host that receives a RST in response to the transmission of an ECN (Explicit Congestion Notification)-setup SYN packet MAY resend a SYN with the CWR (Congestion Window Reduced) and ECE (ECN-Echo) bits cleared. This is meant to deal with faulty middle-boxes that reject connections when a SYN segment has the ECE and CWR bits set. Some faulty middle-boxes (e.g., firewalls) may reject these connection requests with an ICMP soft error of type 3 (Destination Unreachable), code 0 (net unreachable) or 1 (host unreachable), instead of a RST. Therefore, a system that processes ICMP soft error messages as hard errors when they are received for a connection in any of the non-synchronized states could resend the SYN segment with the ECE and CWR bits cleared when an ICMP "net unreachable" (type 3, code 0) or "host unreachable" (type 3, code 1) error message is received in response to a SYN segment that had these bits set.
[RFC3168]は、ECN（明示的な輻輳通知）-SESTUP Synパケットの送信に応じてRSTを受信したホストがCWR（輻輳ウィンドウの削減）およびECE（ECN-ECHO）ビットがクリアされたSynを再送信する可能性があると述べています。これは、SynセグメントがECEおよびCWRビットセットを持っている場合に接続を拒否する誤ったミドルボックスに対処することを目的としています。いくつかの故障したミドルボックス（例：ファイアウォール）は、タイプ3（宛先到達不能）、コード0（ネット到達不能）または1（ホストの到達不能）のICMPソフトエラーでこれらの接続要求を拒否する可能性があります。したがって、ICMPソフトエラーメッセージを、いずれかの非同期状態で接続するために受信したときに硬いエラーとして処理するシステムは、ICMP「Net Uneachable」（Type 3」の場合にECEおよびCWRビットをクリアしてSynセグメントを再送信できます。、コード0）または「ホストの到達不能」（タイプ3、コード1）エラーメッセージは、これらのビットが設定されたSynセグメントに応じて受信されます。
Section 4.2 discusses a more conservative approach than that sketched above, which is implemented in FreeBSD.
セクション4.2では、FreeBSDで実装されている上記のスケッチよりも保守的なアプローチについて説明します。
A more conservative approach than simply treating soft errors as hard errors (as described above) would be to abort a connection in the SYN-SENT or SYN-RECEIVED states only after an ICMP soft error has been received a specified number of times and the SYN segment has been retransmitted more than some specified number of times.
ソフトエラーをハードエラーとして（上記のように）単に扱うよりも保守的なアプローチは、ICMPソフトエラーが指定された回数およびSynを受信した後にのみ、Syn-SentまたはSyn-Receed状態に接続を中止することです。セグメントは、指定された数回以上再送信されています。
Two new parameters would have to be introduced to TCP, to be used only during the connection-establishment phase: MAXSYNREXMIT and MAXSOFTERROR. MAXSYNREXMIT would specify the number of times the SYN segment would have to be retransmitted before a connection is aborted. MAXSOFTERROR would specify the number of ICMP messages indicating soft errors that would have to be received before a connection is aborted.
2つの新しいパラメーターをTCPに導入する必要があります。これは、接続確立段階でのみ使用する必要があります：MaxSynrexmitとMaxsofterror。MaxSynrexmitは、接続が中止される前にSynセグメントを再送信する必要がある回数を指定します。MaxSofterrorは、接続が中止される前に受信する必要があるソフトエラーを示すICMPメッセージの数を指定します。
Two additional state variables would need to be introduced to store additional state information during the connection-establishment phase: "nsynrexmit" and "nsofterror". Both would be initialized to zero when a connection attempt is initiated, with "nsynrexmit" being incremented by one every time the SYN segment is retransmitted and "nsofterror" being incremented by one every time an ICMP message that indicates a soft error is received.
接続確立段階で追加の状態情報を保存するには、2つの追加の状態変数を導入する必要があります。「nsynrexmit」と「nsofterror」です。どちらも接続の試行が開始されるとゼロに初期化され、Synセグメントが再送信されるたびに「nsynrexmit」が1つずつ増加し、ソフトエラーを受信することを示すICMPメッセージが毎回「nsofteror」がインクリメントされます。
A connection in the SYN-SENT or SYN-RECEIVED states would be aborted if "nsynrexmit" was greater than MAXSYNREXMIT and "nsofterror" was simultaneously greater than MAXSOFTERROR.
「nsynrexmit」がmaxsynrexmitよりも大きく、「nsofterror」がMaxsofterrorよりも大きい場合、Syn-SentまたはSyn-Receed状態の接続が中止されます。
This approach would give the network more time to solve the connectivity problem than does simply aborting a connection attempt upon reception of the first soft error. However, it should be noted that, depending on the values chosen for the MAXSYNREXMIT and MAXSOFTERROR parameters, this approach could still lead to long delays between connection-establishment attempts, thus not solving the problem. For example, BSD systems abort connections in the SYN-SENT or the SYN-RECEIVED state when a second ICMP error is received and the SYN segment has been retransmitted more than three times. They also set up a "connection-establishment timer" that imposes an upper limit on the time the connection-establishment attempt has to succeed, which expires after 75 seconds (see [Stevens2], pp. 828- 829). Even when this policy may be better than the three-minute timeout policy specified in [RFC1122], it may still be inappropriate for handling the potential problems described in this document. This more conservative approach has been implemented in BSD systems for more than ten years [Stevens2].
このアプローチは、最初のソフトエラーの受信時に接続の試みを単純に中止するよりも、ネットワークに接続の問題を解決するための時間を増やすでしょう。ただし、MaxSynrexmitおよびMaxsofterrorパラメーターに選択された値に応じて、このアプローチは、接続確立の試みの間の長い遅延につながり、問題を解決しない可能性があることに注意する必要があります。たとえば、BSDシステムは、2番目のICMPエラーが受信され、Synセグメントが3回以上再送信されたときに、Syn-SentまたはSyn-Received状態に接続を中止します。彼らはまた、接続確立の試みが成功する時間に上限を課す「接続確立タイマー」を設定します。[RFC1122]で指定された3分間のタイムアウトポリシーよりもこのポリシーが優れている場合でも、このドキュメントで説明されている潜在的な問題を処理するのは不適切な場合があります。このより保守的なアプローチは、BSDシステムに10年以上にわたって実装されてきました[Stevens2]。
We also note that the approach given in this section is a generalized version of the approach sketched in the previous section. In particular, with MAXSOFTERROR set to 1 and MAXSYNREXMIT set to zero, the schemes are identical.
また、このセクションに記載されているアプローチは、前のセクションでスケッチしたアプローチの一般化バージョンであることに注意してください。特に、Maxsofterrorが1に設定され、MaxSynrexmitがゼロに設定されている場合、スキームは同一です。
The following subsections discuss some possible drawbacks that could arise from use of the non-standard modifications to TCP's reaction to soft errors, which are described in Section 4.1 and Section 4.2.
以下のサブセクションでは、標準以外の変更の使用から、セクション4.1およびセクション4.2で説明されているソフトエラーに対するTCPの反応まで生じる可能性のあるいくつかの欠点について説明します。
In scenarios where a transient network failure affects all of the addresses returned by the name-to-address translation function, all destinations could be unreachable for some short period of time. For example, a mobile system consisting of a cell and a repeater may pass through a tunnel, leading to a loss of connectivity at the repeater, with the repeater sending ICMP soft errors back to the cell. Also, a transient routing problem might lead some intervening router to drop a SYN segment that was meaning to establish a TCP connection and send an ICMP soft error back to the host. Finally, a SYN segment carrying data might get fragmented and some of the resulting fragments might get lost, with the destination host timing out the reassembly process and sending an ICMP soft error back to the sending host (although this particular scenario is unlikely because, while [RFC0793] allows SYN segments to carry data, in practice they do not). In such scenarios, the application could quickly cycle through all the IP addresses in the list and return an error, when it could have let TCP retry a destination a few seconds later, when the transient problem could have disappeared. In this case, the modifications described here make TCP less robust than a standards-compliant implementation.
一時的なネットワーク障害が名前からアドレスへの翻訳関数によって返されるすべてのアドレスに影響を与えるシナリオでは、すべての目的地は、短期間は到達できない可能性があります。たとえば、セルとリピーターで構成されるモバイルシステムは、トンネルを通過し、リピーターでの接続性の損失につながり、リピーターはICMPソフトエラーをセルに送り返します。また、一時的なルーティングの問題により、介入するルーターがTCP接続を確立し、ICMPソフトエラーをホストに送り返すことを意味するSynセグメントをドロップするようになります。最後に、データを運ぶSynセグメントが断片化され、結果のフラグメントの一部が迷子になる可能性があり、宛先ホストが再組み立てプロセスのタイミングを出し、ICMPソフトエラーを送信ホストに送り返すことができます（ただし、この特定のシナリオはありそうもないが、[RFC0793]は、Synセグメントがデータを運ぶことを許可します。実際にはそうではありません）。このようなシナリオでは、アプリケーションはリスト内のすべてのIPアドレスをすばやくサイクリングし、エラーを返すことができます。これにより、TCPが数秒後に宛先を再試行することができた場合、一時的な問題が消えてしまう可能性があります。この場合、ここで説明する変更により、TCPは標準に準拠した実装よりも堅牢性が低くなります。
Additionally, in many cases a domain name maps to a single IP address. In such a case, it might be better to try that address persistently according to normal TCP rules, instead of just aborting the pending connection upon receipt of an ICMP soft error.
さらに、多くの場合、ドメイン名が単一のIPアドレスにマップされます。そのような場合、ICMPソフトエラーを受け取ったときに保留中の接続を中止するだけでなく、通常のTCPルールに従ってそのアドレスを永続的に試す方が良いかもしれません。
There are some scenarios in which transient network failures could be deterministic. For example, consider a scenario in which upstream network connectivity is triggered by network use. That is, network connectivity is instantiated only on an "as needed" basis. In this scenario, the connection triggering the upstream connectivity could deterministically receive ICMP Destination Unreachables while the upstream connectivity is being activated, and thus would be aborted. Again, in this case, the modifications described here make TCP less robust than a standards-compliant implementation.
一時的なネットワーク障害が決定論的である可能性があるいくつかのシナリオがあります。たとえば、ネットワークの使用によって上流のネットワーク接続がトリガーされるシナリオを検討してください。つまり、ネットワーク接続は「必要に応じて」のみでのみインスタンス化されます。このシナリオでは、上流の接続をトリガーする接続は、上流の接続性がアクティブになっている間に、ICMP宛先の到達不能を決定的に受信する可能性があり、したがって中止されます。繰り返しますが、この場合、ここで説明する変更により、TCPは標準に準拠した実装よりも堅牢性が低くなります。
Some NATs respond to an unsolicited inbound SYN segment with an ICMP soft error message. If the system sending the unsolicited SYN segment implements the workaround described in this document, it will abort the connection upon receipt of the ICMP error message, thus probably preventing TCP's simultaneous open from succeeding through the NAT. However, it must be stressed that those NATs described in this section are not BEHAVE-compliant and therefore should implement REQ-4 of [RFC5382] instead.
一部のNATは、ICMPソフトエラーメッセージを使用して、未承諾のインバウンドSynセグメントに応答します。未承諾のSynセグメントを送信するシステムがこのドキュメントに記載されている回避策を実装すると、ICMPエラーメッセージの受信時に接続が中止されるため、おそらくTCPの同時オープンがNATを介して成功するのを防ぎます。ただし、このセクションで説明したこれらのNATは動作に準拠しておらず、したがって[RFC5382]のREQ-4を実装する必要があることを強調する必要があります。
In those scenarios in which such a non-BEHAVE-compliant NAT is deployed, TCP simultaneous opens could fail. While undesirable, this is tolerable in many situations. For instance, a number of host implementations of TCP do not support TCP simultaneous opens [Zuquete].
このような非行動に準拠したNATが展開されるシナリオでは、TCP同時開く可能性があります。望ましくないが、これは多くの状況で許容できる。たとえば、TCPの多くのホスト実装は、TCPの同時オープン[Zuquete]をサポートしていません。
This document describes a non-standard modification to TCP's reaction to soft errors that has been implemented in a variety of TCP implementations. This modification makes TCP abort a connection in the SYN-SENT or the SYN-RECEIVED states when it receives an ICMP error message that indicates a soft error. Therefore, the modification could be exploited to reset valid connections during the connection-establishment phase.
このドキュメントでは、さまざまなTCP実装で実装されているソフトエラーに対するTCPの反応に対する標準以外の変更について説明します。この変更により、TCPは、ソフトエラーを示すICMPエラーメッセージを受信すると、Syn-SentまたはSyn-Received状態の接続を中止します。したがって、変更を悪用して、接続確立段階で有効な接続をリセットできます。
The non-standard workaround described in this document makes TCP more vulnerable to attack, even if only slightly. However, we note that an attacker wishing to reset ongoing TCP connections could send any of the ICMP hard error messages in any connection state.
このドキュメントで説明されている非標準の回避策は、たとえわずかにしか攻撃であっても、TCPを攻撃に対してより脆弱にします。ただし、進行中のTCP接続をリセットしたい攻撃者は、接続状態でICMPハードエラーメッセージのいずれかを送信できることに注意してください。
Generally, TCP backs off its retransmission timer each time it retransmits the SYN segment for the same connection. If a TCP implements the modification described in this document, that is, tries the next address in the list upon receipt of an ICMP error message, it might end up injecting more packets into the network than if it had simply retried the same address a number of times. However, compliant TCP implementations might already incur this behavior (e.g., as a result of cycling through the list of IP addresses in response to RST segments) as there are currently no recommendations on methods for limiting the rate at which SYN segments are sent for connecting to a specific destination.
一般に、TCPは、同じ接続のSynセグメントを再送信するたびに、再送信タイマーを後退させます。TCPがこのドキュメントに記載されている変更、つまりICMPエラーメッセージの受信時にリストの次のアドレスを試している場合、同じアドレスを単に数字を再試行した場合よりも多くのパケットをネットワークに注入することになる可能性があります。時代。ただし、準拠したTCPの実装は、この動作を既に発生する可能性があります（例：RSTセグメントに応じてIPアドレスのリストをサイクリングした結果）。特定の目的地へ。
A discussion of the use of ICMP to perform a variety of attacks against TCP, and a number of counter-measures that minimize the impact of these attacks, can be found in [ICMP-ATTACKS].
TCPに対してさまざまな攻撃を実行するためのICMPの使用に関する議論、およびこれらの攻撃の影響を最小限に抑える多くの対策は、[ICMP攻撃]で見つけることができます。
A discussion of the security issues arising from the use of ICMPv6 can be found in [RFC4443].
ICMPV6の使用から生じるセキュリティの問題の議論は、[RFC4443]に記載されています。
The author wishes to thank Mark Allman, Jari Arkko, David Black, Ron Bonica, Ted Faber, Gorry Fairhurst, Sally Floyd, Juan Fraschini, Tomohiro Fujisaki, Guillermo Gont, Saikat Guha, Alfred Hoenes, Michael Kerrisk, Eddie Kohler, Mika Liljeberg, Arifumi Matsumoto, Sandy Murphy, Carlos Pignataro, Pasi Sarolahti, Pekka Savola, Pyda Srisuresh, Jinmei Tatuya, and Joe Touch for contributing many valuable comments on earlier versions of this document.
著者は、マーク・オールマン、ジャリ・アークコ、デビッド・ブラック、ロン・ボニカ、テッド・フェイバー、ゴーリー・フェアハースト、サリー・フロイド、フアン・フラスチーニ、トモヒロ・フジサキ、ギレルモ・ゴント、サイカット・グハ、アルフレッド・ホーネス、マイケル・ケリス松本、サンディ・マーフィー、カルロス・ピグナタロ、パシ・サロラティ、ペッカ・サヴォラ、ピダ・スリシュシュ、ジンメイ・タトゥヤ、ジョー・タッチは、この文書の以前のバージョンに関する多くの貴重なコメントを提供してくれました。
The author wishes to thank Secretaria de Extension Universitaria at Universidad Tecnologica Nacional and Universidad Tecnologica Nacional/Facultad Regional Haedo for their support in this work.
著者は、この作業への支援について、Universidad tecnologica nacionalとUniversidad tecnologica nacional/fanfultad Regional HaedoのSecreceraria de Extension Universitariaに感謝したいと考えています。
Finally, the author wishes to express deep and heartfelt gratitude to Jorge Oscar Gont and Nelida Garcia for their precious motivation and guidance.
最後に、著者は、貴重な動機と指導のために、ホルヘ・オスカー・ゴントとネリダ・ガルシアに深く心からの感謝を表明したいと考えています。
Mika Liljeberg was the first to describe how their implementation treated soft errors. Based on that, the solution discussed in Section 4.1 was documented in [v6-ON] by Sebastien Roy, Alain Durand, and James Paugh.
Mika Liljebergは、実装がソフトエラーをどのように扱ったかを最初に説明しました。それに基づいて、セクション4.1で説明した解決策は、セバスチャン・ロイ、アラン・デュランド、ジェームズ・ポーの[V6-On]で文書化されました。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）、RFC 4443、2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[Gont] Gont, F., "On the problem of long delays between connection-establishment attempts in TCP", Work in Progress, January 2009.
[Gont] Gont、F。、「TCPにおける接続確立の試みの間の長い遅延の問題について」、2009年1月、進行中の作業。
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2008.
[ICMP-attacks] Gont、F。、「TCPに対するICMP攻撃」、2008年10月、進行中の作業。
[Linux] The Linux Project, "http://www.kernel.org".
[Linux] Linuxプロジェクト、「http://www.kernel.org」。
[RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, July 1982.
[RFC0816]クラーク、D。、「断層分離と回復」、RFC 816、1982年7月。
[RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007.
[RFC4943] Roy、S.、Durand、A。、およびJ. Paugh、「IPv6 Neighbor Discovery On-Link Assuttionが有害と見なされる」、RFC 4943、2007年9月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT行動要件」、BCP 142、RFC 5382、2008年10月。
[Shneiderman] Shneiderman, B., "Response Time and Display Rate in Human Performance with Computers", ACM Computing Surveys, 1984.
[Shneiderman] Shneiderman、B。、「コンピューターによる人間のパフォーマンスにおける応答時間と表示率」、ACMコンピューティング調査、1984。
[Stevens] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[スティーブンス]スティーブンス、W。、「TCP/IP Illustrated、Volume 1：The Protocols」、Addison-Wesley、1994。
[Stevens2] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994.
[Stevens2] Wright、G。and W. Stevens、「TCP/IP Illustrated、Volume 2：The Information」、Addison-Wesley、1994。
[Thadani] Thadani, A., "Interactive User Productivity", IBM Systems Journal, No. 1, 1981.
[Thadani] Thadani、A。、「Interactiveユーザーの生産性」、IBM Systems Journal、No。1、1981。
[Zuquete] Zuquete, A., "Improving the functionality of SYN cookies", 6th IFIP Communications and Multimedia Security Conference (CMS 2002), 2002.
[Zuquete] Zuquete、A。、「Syn Cookieの機能の改善」、第6回IFIP Communications and Multimedia Security Conference（CMS 2002）、2002。
[v6-ON] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", Work in Progress, July 2004.
[V6-On] Roy、S.、Durand、A。、およびJ. Paugh、「デフォルトでデュアルスタックIPv6の問題」、2004年7月、作業中。
Author's Address
著者の連絡先
Fernando Gont Universidad Tecnologica Nacional / Facultad Regional Haedo Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
フェルナンド・ゴント大学テクノロジカ・ナシオナル /ファカルカル地域ハード・エヴァリスト・キャリーゴ2644ハード、地方de buenos Aires 1706 Argentina
Phone: +54 11 4650 8472
EMail: fernando@gont.com.ar
URI: http://www.gont.com.ar