[要約] RFC 6633は、ICMP Source Quenchメッセージの非推奨化に関するものであり、ネットワークの過負荷を管理するための代替手段を提案しています。目的は、ネットワークのパフォーマンスを向上させ、より効果的なトラフィック制御を実現することです。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6633 UTN-FRH / SI6 Networks
Updates: 792, 1122, 1812 May 2012
Category: Standards Track
ISSN: 2070-1721
Deprecation of ICMP Source Quench Messages
ICMP Source Quenchメッセージの廃止
Abstract
概要
This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812.
このドキュメントでは、トランスポートプロトコルによるICMPソースクエンチメッセージの使用を正式に廃止し、RFC 792、RFC 1122、およびRFC 1812を正式に更新しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6633.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6633で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. ICMP Source Quench Messages .....................................3
3. Updating RFC 1122 ...............................................3
4. Updating RFC 1812 ...............................................4
5. Clarification for UDP, SCTP, and DCCP ...........................4
6. General Advice to Transport Protocols ...........................4
7. Recommendation Regarding RFC 1016 ...............................5
8. Security Considerations .........................................5
9. IANA Considerations .............................................5
10. Acknowledgements ...............................................5
11. References .....................................................6
11.1. Normative References ......................................6
11.2. Informative References ....................................7
Appendix A. Survey of Support of ICMP Source Quench in Some
Popular TCP/IP Implementations ........................8
The ICMP specification [RFC0792] defined the ICMP Source Quench message (type 4, code 0), which was meant as a mechanism for congestion control. ICMP Source Quench has been known to be an ineffective (and unfair) antidote for congestion, and generation of ICMP Source Quench messages by routers has been formally deprecated by [RFC1812] since 1995. However, reaction to ICMP Source Quench messages in transport protocols has never been formally deprecated.
ICMP仕様[RFC0792]は、輻輳制御のメカニズムとして意図されたICMP Source Quenchメッセージ（タイプ4、コード0）を定義しました。 ICMP Source Quenchは、輻輳に対して無効（かつ不公平）な解毒剤であることが知られており、ルーターによるICMP Source Quenchメッセージの生成は、1995年以来[RFC1812]によって正式に非推奨になっています。しかし、トランスポートプロトコルでのICMP Source Quenchメッセージに対する反応は、正式に廃止されたことはありません。
This document formally deprecates reaction to ICMP Source Quench messages by transport protocols such as TCP [RFC0793], formally updating [RFC0792], [RFC1122], and [RFC1812]. Additionally, it provides a recommendation against the implementation of [RFC1016]. The rationale for these specification updates is as follows:
このドキュメントは、TCP [RFC0793]、正式に更新された[RFC0792]、[RFC1122]、および[RFC1812]などのトランスポートプロトコルによるICMP Source Quenchメッセージへの反応を正式に廃止します。さらに、[RFC1016]の実装に対する推奨事項を提供します。これらの仕様更新の根拠は次のとおりです。
o Processing of ICMP Source Quench messages by routers has been deprecated for nearly 17 years [RFC1812].
o ルーターによるICMP Source Quenchメッセージの処理は、ほぼ17年間非推奨となっています[RFC1812]。
o Virtually all popular host implementations have removed support for ICMP Source Quench messages since (at least) 2005 [RFC5927].
o ほぼすべての一般的なホスト実装は、（少なくとも）2005年以降、ICMP Source Quenchメッセージのサポートを削除しています[RFC5927]。
o Widespread deployment of ICMP filtering makes it impossible to rely on ICMP Source Quench messages for congestion control.
o ICMPフィルタリングの普及により、輻輳制御のためにICMP Source Quenchメッセージに依存することができなくなりました。
o The IETF has moved away from ICMP Source Quench messages for congestion control (e.g., note the development of Explicit Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6 [RFC4443] does not even specify a Source Quench message).
o IETFは、輻輳制御のためにICMPソースクエンチメッセージから離れました（たとえば、明示的輻輳通知（ECN）[RFC3168]の開発と、ICMPv6 [RFC4443]がソースクエンチメッセージさえ指定していないという事実に注意してください）。
ICMP Source Quench messages are not normally seen in the deployed Internet and were considered rare at least as far back as 1994 [Floyd1994].
ICMP Source Quenchメッセージは通常、展開されたインターネットでは見られず、少なくとも1994年まではまれであると考えられていました[Floyd1994]。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The ICMP specification [RFC0792] defined the ICMP Source Quench message (type 4, code 0), which was meant to provide a mechanism for congestion control. The Host Requirements RFC [RFC1122] stated in Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages by slowing transmission on the connection, and further added that the RECOMMENDED procedure was to put the corresponding connection in the slow-start phase of TCP's congestion control algorithm [RFC5681].
ICMP仕様[RFC0792]は、ICMP Source Quenchメッセージ（タイプ4、コード0）を定義しました。これは、輻輳制御のメカニズムを提供することを目的としています。 4.2.3.9項に記載されているホスト要件RFC [RFC1122]は、ホストが接続での送信を遅くすることによってICMP Source Quenchメッセージに反応する必要があることを述べ、さらに、推奨手順では対応する接続をTCPのスロースタートフェーズに置くことを追加しました。輻輳制御アルゴリズム[RFC5681]。
[RFC1812] noted that research suggested that ICMP Source Quench was an ineffective (and unfair) antidote for congestion, and formally deprecated the generation of ICMP Source Quench messages by routers, stating that routers SHOULD NOT send ICMP Source Quench messages in response to congestion.
[RFC1812]は、ICMP Source Quenchは輻輳に対して無効（かつ不公平）な解毒剤であると研究が示唆しており、ルーターによるICMP Source Quenchメッセージの生成を正式に非推奨とし、ルーターは輻輳に応答してICMP Source Quenchメッセージを送信してはならないことを述べた[RFC1812]。
[RFC5927] discussed the use of ICMP Source Quench messages for performing "blind throughput-reduction" attacks, and noted that most TCP implementations silently ignore ICMP Source Quench messages.
[RFC5927]は、「ブラインドスループット削減」攻撃を実行するためのICMPソースクエンチメッセージの使用について説明し、ほとんどのTCP実装がICMPソースクエンチメッセージを黙って無視することを指摘しました。
We note that TCP implements its own congestion control mechanisms [RFC5681] [RFC3168], which do not depend on ICMP Source Quench messages.
TCPは独自の輻輳制御メカニズム[RFC5681] [RFC3168]を実装しており、ICMP Source Quenchメッセージに依存しないことに注意してください。
It is interesting to note that ICMPv6 [RFC4443] does not specify a Source Quench message.
ICMPv6 [RFC4443]がSource Quenchメッセージを指定していないことに注意することは興味深いです。
This document hereby updates Section 3.2.2.3 of [RFC1122] as follows:
このドキュメントは、[RFC1122]のセクション3.2.2.3を次のように更新します。
A host MUST NOT send ICMP Source Quench messages.
ホストはICMP Source Quenchメッセージを送信してはいけません。
If a Source Quench message is received, the IP layer MAY silently discard it.
Source Quenchメッセージが受信された場合、IP層はメッセージを表示せずに破棄する場合があります。
Section 4.2.3.9 of [RFC1122] is updated as follows:
[RFC1122]のセクション4.2.3.9が次のように更新されました。
TCP MUST silently discard any received ICMP Source Quench messages.
TCPは、受信したICMP Source Quenchメッセージをサイレントに破棄する必要があります。
The consensus of the TSV WG was that there are no valid reasons for a host to generate or react to an ICMP Source Quench message in the current Internet. The recommendation that a sender "MUST NOT" send an ICMP Source Quench message is because there is no known valid reason for a host to generate this message. The only known impact of a sender ignoring this requirement is that it may necessarily consume network and endpoint resources. Discarding ICMP Source Quench messages at the Internet layer (rather than at the transport layer) is a performance optimization that is permitted by this update.
TSV WGのコンセンサスは、ホストが現在のインターネットでICMP Source Quenchメッセージを生成またはそれに反応する正当な理由がないということでした。送信者がICMP Source Quenchメッセージを送信する必要があることを推奨するのは、ホストがこのメッセージを生成する有効な理由がわかっていないためです。この要件を無視する送信者の唯一の既知の影響は、ネットワークとエンドポイントのリソースを必ず消費する可能性があることです。 ICMP Source Quenchメッセージを（トランスポート層ではなく）インターネット層で破棄することは、この更新で許可されるパフォーマンスの最適化です。
This document hereby updates Section 4.3.3.3 of [RFC1812] as follows:
このドキュメントは、[RFC1812]のセクション4.3.3.3を次のように更新します。
A router MUST ignore any ICMP Source Quench messages it receives.
ルーターは、受信するICMP Source Quenchメッセージを無視する必要があります。
The consensus of the TSV WG was that there are no valid reasons for a router to react to ICMP Source Quench messages in the current Internet.
TSV WGのコンセンサスは、ルーターが現在のインターネットのICMP Source Quenchメッセージに反応する正当な理由がないということでした。
UDP [RFC0768] did not explicitly specify support for ICMP Source Quench messages. Hereby, we clarify that UDP endpoints MUST silently discard received ICMP Source Quench messages.
UDP [RFC0768]は、ICMP Source Quenchメッセージのサポートを明示的に指定していませんでした。これにより、UDPエンドポイントは受信したICMPソースクエンチメッセージを静かに破棄する必要があることを明確にします。
It is understood that SCTP [RFC4960] and DCCP [RFC4340] did not specify support for processing received ICMP Source Quench messages. Hereby, we clarify that DCCP and SCTP endpoints MUST silently discard received ICMP Source Quench messages.
SCTP [RFC4960]およびDCCP [RFC4340]は、受信したICMP Source Quenchメッセージの処理のサポートを指定していないことがわかります。これにより、DCCPエンドポイントとSCTPエンドポイントは、受信したICMPソースクエンチメッセージを静かに破棄する必要があることを明確にします。
If a Source Quench message is received by any other transport-protocol instance, it MUST be silently ignored.
Source Quenchメッセージが他のトランスポートプロトコルインスタンスによって受信された場合、それは黙って無視されなければなりません（MUST）。
The TSV WG is not aware of any mechanism that requires processing of these messages and therefore expects other transports to follow the recommendations in Section 3. Note that since generation of ICMP Source Quench messages has been deprecated for many years, and since this document additionally deprecates reaction to ICMP Source Quench messages by IETF-specified transports, future applications cannot expect to receive these messages.
TSV WGはこれらのメッセージの処理を必要とするメカニズムを認識していないため、他のトランスポートがセクション3の推奨事項に従うことを期待しています。ICMPSource Quenchメッセージの生成は長年にわたって非推奨になっているため、このドキュメントではさらに非推奨となっているためIETF指定のトランスポートによるICMP Source Quenchメッセージへの反応、将来のアプリケーションはこれらのメッセージを受信することを期待できません。
[RFC1016] describes an experimental approach to the handling of ICMP Source Quench messages in hosts that was considered in 1987. Even though RFC 1016 has never been on the IETF Standards Track, for clarity and avoidance of doubt we note that the approach described in [RFC1016] MUST NOT be implemented.
[RFC1016]では、1987年に検討された、ホストでのICMPソースクエンチメッセージの処理に対する実験的なアプローチについて説明します。RFC1016はIETF標準トラックに参加したことはありませんが、明確化と疑いを避けるために、[ RFC1016]を実装してはなりません（MUST NOT）。
ICMP Source Quench messages could be leveraged for performing blind throughput-reduction attacks against TCP and similar protocols. This attack vector, along with possible countermeasures, has been discussed in great detail in [RFC5927] and [CPNI-TCP]. Silently ignoring ICMP Source Quench messages, as specified in this document, eliminates the aforementioned attack vector.
ICMP Source Quenchメッセージは、TCPおよび類似のプロトコルに対するブラインドスループット低下攻撃を実行するために利用できます。この攻撃ベクトルと考えられる対策は、[RFC5927]と[CPNI-TCP]で詳細に説明されています。このドキュメントで指定されているように、ICMP Source Quenchメッセージを黙って無視することで、前述の攻撃ベクトルが排除されます。
For current TCP implementations, receipt of an ICMP Source Quench message should not result in security issues because, as noted in [RFC5927] and [CPNI-TCP], virtually all current versions of popular TCP implementations already silently ignore ICMP Source Quench messages. This is also the case for SCTP and DCCP implementations.
現在のTCP実装では、[RFC5927]と[CPNI-TCP]に記載されているように、一般的なTCP実装のほぼすべての現在のバージョンがICMPソースクエンチメッセージを無視して無視しているため、ICMPソースクエンチメッセージを受信してもセキュリティ上の問題は発生しません。これは、SCTPおよびDCCPの実装にも当てはまります。
Hosts, security gateways, and firewalls MUST silently discard received ICMP Source Quench packets and SHOULD log such drops as a security fault with at least minimal details (IP Source Address, IP Destination Address, ICMP message type, and date/time the packet was seen).
ホスト、セキュリティゲートウェイ、およびファイアウォールは、受信したICMPソースクエンチパケットをサイレントに破棄する必要があり、少なくとも最小限の詳細（IPソースアドレス、IP宛先アドレス、ICMPメッセージタイプ、およびパケットが見られた日付/時刻）でセキュリティ障害などのドロップを記録する必要があります（SHOULD）。 ）。
We note that security devices such as the Snort Network Intrusion Detection System (NIDS) have logged ICMP Source Quench messages as such for more than ten years [Anderson2002].
Snort Network Intrusion Detection System（NIDS）などのセキュリティデバイスは、ICMP Source Quenchメッセージを10年以上記録している[Anderson2002]。
IANA has marked ICMP type 4 (Source Quench) as "Deprecated" in the ICMP Parameters registry [ICMPPARREG] with a reference to this document.
IANAは、このドキュメントを参照して、ICMPパラメータレジストリ[ICMPPARREG]でICMPタイプ4（ソースクエンチ）を「非推奨」としてマークしました。
The author of this document would like to thank Ran Atkinson, who contributed text that was incorporated into this document and also provided valuable feedback on earlier versions of this document.
このドキュメントの作成者は、このドキュメントに組み込まれたテキストを提供し、このドキュメントの以前のバージョンに関する貴重なフィードバックを提供してくれたRan Atkinsonに感謝します。
The author of this document would like to thank (in alphabetical order) Fred Baker, David Black, Scott Bradner, James Carlson, Antonio De Simone, Wesley Eddy, Gorry Fairhurst, Alfred Hoenes, Mahesh Jethanandani, Kathleen Moriarty, Carlos Pignataro, James Polk, Anantha Ramaiah, Randall Stewart, Dan Wing, and Andrew Yourtchenko, for providing valuable feedback on earlier versions of this document. This document has also benefited from discussions within the TCPM Working Group while working on [RFC5927].
このドキュメントの作成者に感謝します（アルファベット順）Fred Baker、David Black、Scott Bradner、James Carlson、Antonio De Simone、Wesley Eddy、Gorry Fairhurst、Alfred Hoenes、Mahesh Jethanandani、Kathleen Moriarty、Carlos Pignataro、James Polk 、Anantha Ramaiah、Randall Stewart、Dan Wing、Andrew Yourtchenko。このドキュメントの以前のバージョンに関する貴重なフィードバックを提供してくれました。このドキュメントは、[RFC5927]に取り組んでいる間、TCPMワーキンググループ内の議論からも恩恵を受けました。
Fernando Gont wishes to thank Jorge Oscar Gont, Nelida Garcia, and Guillermo Gont for their love and support.
フェルナンドゴントは、ホルヘオスカーゴント、ネリダガルシア、ギジェルモゴントの愛とサポートに感謝します。
Fernando Gont's attendance to IETF meetings was supported by ISOC's "Fellowship to the IETF" program.
フェルナンドゴントのIETF会議への出席は、ISOCの「IETFへのフェローシップ」プログラムによってサポートされました。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[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。、「Transmission Control Protocol」、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月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、2009年9月。
[Anderson2002] Anderson, D., Fong, M., and A. Valdes, "Heterogeneous Sensor Correlation: A Case Study of Live Traffic Analysis", Proceedings of the 3rd Annual IEEE Information Assurance Workshop New York, NY, USA, 2002.
[Anderson2002] Anderson、D.、Fong、M.、and A. Valdes、 "Heterogeneous Sensor Correlation：A Case Study of Live Traffic Analysis"、Proceedings of the 3 Annual Annual IEEE Information Assurance Workshop New York、NY、USA、2002。
[CPNI-TCP] CPNI, "Security Assessment of the Transmission Control Protocol (TCP)", 2009, <http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf>.
[CPNI-TCP] CPNI、「伝送制御プロトコル（TCP）のセキュリティ評価」、2009、<http://www.gont.com.ar/papers/ tn-03-09-security-assessment-TCP.pdf >。
[Floyd1994] Floyd, S., "TCP and Explicit Congestion Notification", ACM CCR New York, NY, Volume 24, Issue 5, October 1994.
[Floyd1994] Floyd、S。、「TCP and Explicit Congestion Notification」、ACM CCR New York、NY、Volume 24、Issue 5、1994年10月。
[FreeBSD] The FreeBSD Project, <http://www.freebsd.org>.
[FreeBSD] FreeBSDプロジェクト、<http://www.freebsd.org>。
[ICMPPARREG] IANA, "Internet Control Message Protocol (ICMP) Parameters", <http://www.iana.org/assignments/icmp-parameters>.
[ICMPPARREG] IANA、「インターネット制御メッセージプロトコル（ICMP）パラメータ」、<http://www.iana.org/assignments/icmp-parameters>。
[Linux] The Linux Project, <http://www.kernel.org>.
[Linux] Linuxプロジェクト、<http://www.kernel.org>。
[NetBSD] The NetBSD Project, <http://www.netbsd.org>.
[NetBSD] NetBSDプロジェクト、<http://www.netbsd.org>。
[OpenBSD] The OpenBSD Project, <http://www.openbsd.org>.
[OpenBSD] OpenBSDプロジェクト、<http://www.openbsd.org>。
[OpenSolaris] OpenSolaris, <http://www.opensolaris.org>.
[OpenSolaris] OpenSolaris、<http://www.opensolaris.org>。
[RFC1016] Prue, W. and J. Postel, "Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)", RFC 1016, July 1987.
[RFC1016] Prue、W。およびJ. Postel、「ホストがソースクエンチで実行できること：ソースクエンチ導入遅延（SQuID）」、RFC 1016、1987年7月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「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、「インターネット制御メッセージプロトコル（ICMPv6）、インターネットプロトコルバージョン6（IPv6）仕様」、RFC 4443、2006年3月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927] Gont、F。、「TCPに対するICMP攻撃」、RFC 5927、2010年7月。
Appendix A. Survey of Support of ICMP Source Quench in Some Popular TCP/IP Implementations
付録A.一部の一般的なTCP / IP実装におけるICMPソースクエンチのサポートの調査
A large number of implementations completely ignore ICMP Source Quench messages meant for TCP connections. This behavior has been implemented in, at least, Linux [Linux] since 2004, and in FreeBSD [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since 2005. Additionally, OpenSolaris [OpenSolaris] has always shipped with support for ICMP Source Quench messages disabled.
多数の実装が、TCP接続用のICMP Source Quenchメッセージを完全に無視します。この動作は、少なくとも2004年以降はLinux [Linux]、2005年以降はFreeBSD [FreeBSD]、NetBSD [NetBSD]、OpenBSD [OpenBSD]、およびSolaris 10に実装されています。さらに、OpenSolaris [OpenSolaris]には常にICMP Source Quenchメッセージのサポートが無効になっています。
Author's Address
著者のアドレス
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com