Network Working Group F. Gont
Request for Comments: 5461 UTN/FRH
Category: Informational February 2009
TCP's Reaction to Soft Errors
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この文書では、非標準が記載されているが、広く実装、これらのエラーメッセージを受信したときに、接続要求を保留拒否ICMPソフトエラーメッセージのTCPの扱いに変更。この動作は、デフォルトで有効になってIPv6を有するデュアルスタックノードが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].
障害分離および障害回復：ネットワーク障害の取り扱いは、二つの異なるアクションに分けることができます。障害分離は、ホストとルータは、ネットワーク障害があることを決定するために取る行動から成ります。障害回復は、他の一方で、ホストとルータがネットワーク障害[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接続を確立しようとしたときに発生する可能性のある問題を分析します。また、それはデフォルトで有効にIPv6を有するデュアルスタックノードが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]はソフトエラーを示すICMPメッセージは、ICMP「宛先到達不能」コード0（ネットワーク到達不能）、1（到達不可能ホスト）であることを、セクション4.2.3.9において、状態、および5（ソースルートが失敗しました）。 ICMPコード0（トランジットで超過生きる時間）と1（超過フラグメント再構成時間）「時間超過しました」。およびICMP「パラメータ問題」。 [RFC1122]が書き込まれたときのICMPv6が存在しなかったにもかかわらず、一方が「到達不能宛先」のICMPv6にソフトエラーの概念を外挿することができコード0（宛先へのNoルート）及び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レイヤは、ネットワーク障害[RFC1122]の意識を高めるために、対応するTCPインスタンスにこのメッセージを渡すであろう。 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]は、ハードエラーを示すICMPエラーメッセージを受信したときにTCPが接続を中止すべきであることを、セクション4.2.3.9で、述べています。このポリシーは、ハードエラーが短期的に変更されることはありませんネットワークエラー条件を示すよう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ハードエラーが同期状態[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の送信側が可能後で使用するために情報を記録することができる（参照[スティーブンス]、頁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]はソフトエラーを示すICMPエラーメッセージを受信したときにTCPが接続を中止してはいけませんことを、セクション4.2.3.9で、述べています。このポリシーは、ソフトエラーがうまくいけば、短期的に解決される一時的なネットワーク障害が発生しているとして、再送信のいずれかが成功する、という前提に基づいています。
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は、より具体的なエラーメッセージをユーザに提供するためにこの情報を使用することができる（参照[スティーブンス]、頁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アドレスに解決先と通信しようとしているシナリオを検討してください。ローカルホスト上のアプリケーションは、1つは、[RFC1123]を成功するまで、通常はIPアドレスのリストを巡回、宛先ホストとの接続を確立しようとします。いくつかの（すべてではない）返されたリスト内のアドレスのは永久に到達不能であることを仮定します。そのような恒久的に到達できないアドレスがリストの最初のであれば、アプリケーションはおそらく最初にそれを使用して代替アドレスをしようとする前にタイムアウト待ちをブロックしようとします。
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].
ほとんどのアプリケーションがシリアルに名前とアドレスの関数によって返されたアドレスを試しながら、これは確かに唯一可能なアプローチではないことは注目に値します。一つは、おそらくこの文書[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].
問題のこの種が定期的に起こる可能性のある特定のシナリオでは、デフォルトで有効にIPv6を有するデュアルスタックノードが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]で議論するように、接続性の欠如が送信ノードに通知されたか否かが異なる。このシナリオの二つの可能な変異体が存在します。
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.
これらのシナリオでいる静かに破棄された宛先に送信されるパケットとNOの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.
レガシーノードが宛先がオンリンクであると仮定、またはファイアウォールまたは範囲の境界を適用する他のシステムのICMPv6エラーを送信する場合、送信ノードがシグナリングするためのデフォルトルータと近隣到達不能検出（NUD）[RFC4861]は失敗していないシナリオでは到達不能問題の。ソフトエラーを示すICMPエラーメッセージを受信したときただし、2.2節で述べたように、対応のTCP実装は、接続を中断しません。
4. Deployed Workarounds for Long Delays between Connection-Establishment Attempts
コネクション確立の試みの間に長い時間がかかるため4.配備回避策
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節で述べたように、障害復旧アクションが報告されるエラーの種類にもエラーが報告され、これに対して、接続の状態にないのみに依存するため、それが意味をなすことがあります。例えば、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状態での接続のために受信されたときにハードエラーとして扱いしています。たとえば、この回避策は（1996年発売）、バージョン2.0.0 [Linuxの]以来、Linuxカーネルに実装されています。しかし、この変更は、これらのICMPエラーメッセージがソフトエラー条件とそれを示すと述べている[RFC1122]のセクション4.2.3.9に違反することに留意すべきで、そのため、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]はSYNパケット-setup ECN（明示的輻輳通知）の送信に応答してRSTを受信するホストがCWRとSYN（輻輳ウィンドウを減少）及びクリアECE（ECN-エコー）ビットを再送するかもしれないことを述べています。これは、SYNセグメントがECEを有し、CWRビットが設定されたときに接続を拒否不良ミドルボックスを扱うことを意味します。いくつかの故障ミドルボックス（例えば、ファイアウォール）の代わりにRSTの、タイプ3（宛先到達不能）、コード0（ネット到達不能）または1（到達不可能ホスト）のICMPソフトエラーとこれらの接続要求を拒否することができます。したがって、それらはクリアECEとCWRビットのSYNセグメントを再送信する可能性が非同期状態のいずれかに接続するために受信された場合、ハードエラーとしてICMPソフトエラーメッセージを処理するシステムときICMP「ネット到達不能」（タイプ3 、コード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-RECEIVED状態の接続を中止することであろうセグメントは、指定された回数より多く再送されてきました。
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.
MAXSYNREXMITとMAXSOFTERROR：二つの新しいパラメータは、接続確立フェーズで使用されるように、TCPに導入しなければならないであろう。 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.
「nsynrexmit」と「nsofterror」：二つの追加状態変数は、接続確立フェーズ中に追加の状態情報を格納するために導入される必要があるであろう。接続の試行が「nsynrexmit」は一つによってSYNセグメントが再送され、「nsofterror」はいずれかによってソフトエラーを示すICMPメッセージが受信されるたびにインクリメントされる毎にインクリメントされると、開始されたときの両方がゼロに初期化されます。
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-RECEIVED状態の接続は中断されるであろう。
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システムは、SYN-SENTまたは第二のICMPエラーが受信され、SYNセグメントが回以上再送信されたSYN-受信した状態で接続を中止します。彼らはまた、（、[Stevens2]頁を参照してください。828- 829）を75秒後に期限が切れるコネクション確立の試みが成功するために持っている時間が、上の上限を課し、「コネクション確立タイマー」を設定します。このポリシーは、[RFC1122]で指定された3分のタイムアウトポリシーよりも良いかもしれ場合でも、それはまだ、この文書で説明する潜在的な問題を扱うには不適切かもしれません。これより保守的なアプローチは、十年以上[Stevens2]のためのBSDシステムに実装されています。
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セグメントを送信するシステムは、この文書に記載されている回避策を実装している場合、それはこのように、おそらくNAT経由続くからTCPの同時オープンを防止し、ICMPエラーメッセージの受信時に接続を中止します。しかし、このセクションに記載されているものNATの代わりにREQ-4 [RFC5382]を実装する必要があり、従って対応-挙動していないことを強調しなければなりません。
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].
このような非BEHAVE準拠の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の反応に非標準の変更について説明します。この変更は、それがソフトエラーを示してICMPエラーメッセージを受信したときにTCPが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実装は、すでにSYNセグメントを接続するために送信される速度を制限するための方法には何の勧告が現在存在しないとして（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].
ICMPの使用の議論は、TCPに対する攻撃の様々な、およびこれらの攻撃の影響を最小限に抑える対策の数を実行するために、[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.
著者はマーク・オールマン、ヤリArkko、デビッド・ブラック、ロンBonica、テッド・フェーバー、Gorry Fairhurst、サリー・フロイド、フアンFraschini、藤崎智宏、ギジェルモGont、Saikatグハ、アルフレッドHoenes、マイケル・ケリスク、エディー・コーラー、ミカLiljebergに感謝したいです、このドキュメントの以前のバージョンには、多くの貴重なコメントを貢献するためArifumi松本、サンディマーフィー、カルロスPignataro、パシSarolahti、ペッカSavola、Pyda Srisuresh、神明達也、そしてジョー・タッチ。
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.
作者はこの作品で彼らのサポートのために大学Tecnologica議事堂、大学Tecnologica国立/ Facultad地域HaedoでSecretariaデ拡張Universitariaのを感謝したいです。
Finally, the author wishes to express deep and heartfelt gratitude to Jorge Oscar Gont and Nelida Garcia for their precious motivation and guidance.
最後に、著者は彼らの貴重なモチベーションと指導のためのホルヘオスカーGontとNelidaガルシアに深く心からの感謝の意を表したいと考えています。
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.
ミカLiljebergは、その実装はソフトエラーを処理する方法について説明した最初の。それに基づいて、4.1節で述べた溶液はセバスチャン・ロイ、アラン・デュラン、とジェームズPaughで[V6-ON]に記載されていました。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]ブレーデン、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン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.、シンプソン、W.、およびH.ソリマン、 "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.
「TCPでのコネクション確立の試行間の長い遅延の問題について」[Gont] Gont、F.、進歩、2009年1月の作業。
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2008.
[ICMP攻撃] 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]ロイ、S.、デュラン、A.、およびJ. Paugh、2007年9月、RFC 4943、 "IPv6の近隣探索オンリンク仮定が有害と考えられ"。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、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イラスト、第1巻：プロトコル"、アディソン・ウェズリー、1994。
[Stevens2] Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: The Implementation", Addison-Wesley, 1994.
[Stevens2]ライト、G.とW.スティーブンス、 "TCP / IPイラスト、2巻：インプリメンテーション"、アディソン・ウェズリー、1994。
[Thadani] Thadani, A., "Interactive User Productivity", IBM Systems Journal, No. 1, 1981.
[Tadani] tadani、B。、 "対話型ユーザーの生産性"、イブン・システムズ・ジャーナル、ありません。 1、1981。
[Zuquete] Zuquete, A., "Improving the functionality of SYN cookies", 6th IFIP Communications and Multimedia Security Conference (CMS 2002), 2002.
[Zuquete] Zuquete、A.、第六IFIP通信・マルチメディアセキュリティ会議（CMS 2002）、2002年 "SYNクッキーの機能を向上させます"。
[v6-ON] Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack IPv6 on by Default", Work in Progress, July 2004.
[V6-ON]ロイ、S.、デュラン、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
フェルナンドGont大学Tecnologicaナシオナル/ Facultad地域Haedoエバリスト・キャリエゴ2644 Haedo、1706ブエノスアイレス州アルゼンチン
Phone: +54 11 4650 8472 EMail: fernando@gont.com.ar URI: http://www.gont.com.ar
電話：+54 11 4650 8472 Eメール：URI fernando@gont.com.ar：http://www.gont.com.ar