Network Working Group R. Denis-Courmont
Request for Comments: 5597 VideoLAN project
BCP: 150 September 2009
Category: Best Current Practice
Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol
ネットワークアドレス変換（NAT）データグラム輻輳制御プロトコルのための行動の要件
Abstract
抽象
This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). These requirements allow DCCP applications, such as streaming applications, to operate consistently, and they are very similar to the TCP requirements for NATs, which have already been published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly.
この文書では、データグラム輻輳制御プロトコル（DCCP）を扱うNATのための要件のセットを定義します。これらの要件は、このようなストリーミングアプリケーションとしてDCCPアプリケーションは、一貫して動作することを可能にする、と彼らはすでにIETFによって公表されているNATのためのTCPの要件、と非常によく似ています。 NATの要件のこのセットを満たしていることを保証することは非常にDCCPを使用するアプリケーションが正しく機能する可能性を高めるだろう。
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright and License 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. 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 BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3
4. DCCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . . 5
6. Application-Level Gateways . . . . . . . . . . . . . . . . . . 5
7. Other Requirements Applicable to DCCP . . . . . . . . . . . . . 5
8. Requirements Specific to DCCP . . . . . . . . . . . . . . . . . 6
9. DCCP without NAT Support . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
For historical reasons, NAT devices are not typically capable of handling datagrams and flows for applications that use the Datagram Congestion Control Protocol (DCCP) [RFC4340].
歴史的な理由のために、NATデバイスは、典型的には、取り扱いデータグラムすることができないデータグラム輻輳制御プロトコル（DCCP）[RFC4340]を使用するアプリケーションのために流れます。
This memo discusses the technical issues involved and proposes a set of requirements for NAT devices to handle DCCP in a way that enables communications when either or both of the DCCP endpoints are located behind one or more NAT devices. All definitions and requirements in [RFC4787] are inherited here. The requirements are otherwise designed similarly to those in [RFC5382], from which this memo borrows its structure and much of its content.
このメモは、関係する技術的な問題について説明し、DCCPのエンドポイントのいずれかまたは両方が、1つまたは複数のNATデバイスの背後に配置されているときの通信を可能にする方法でDCCPを処理するために、NATデバイスのための一連の要件を提案しています。 [RFC4787]ですべての定義と要件は、ここで継承されます。要件は、そうでなければ、このメモは、その構造およびそのコンテンツの多くを借り、そこから、[RFC5382]のものと同様に設計されています。
Note however that, if both endpoints are hindered by NAT devices, the normal model for DCCP of asymmetric connection will not work. A simultaneous-open must be performed, as in [RFC5596]. Also, a separate, unspecified mechanism may be needed, such as Unilateral Self Address Fixing (UNSAF) [RFC3424] protocols, if an endpoint needs to learn its own external NAT mappings.
両方のエンドポイントがNATデバイスによって妨げている場合は、しかしなお、非対称接続のDCCPのための正常なモデルでは動作しません。同時オープンは[RFC5596]と同様に、行わなければなりません。エンドポイントは、自身の外部NATマッピングを学習する必要がある場合も、別の、詳細不明のメカニズムは、そのような一方的自己アドレス固定（UNSAF）[RFC3424]のプロトコルとして、必要になる場合があります。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This document uses the term "DCCP connection" to refer to individual DCCP flows, as uniquely identified by the quadruple (source and destination IP addresses and DCCP ports) at a given time.
この文書は一意四重極（ソースおよび宛先IPアドレスとDCCPポート）によって識別される所与の時間に、個々のDCCPフローを参照するために用語「DCCP接続」を使用します。
This document uses the term "NAT mapping" to refer to a state at the NAT that is necessary for network address and port translation of DCCP connections. This document also uses the terms "endpoint-independent mapping", "address-dependent mapping", "address and port-dependent mapping", "filtering behavior", "endpoint-independent filtering", "address-dependent filtering", "address and port-dependent filtering", "port assignment", "port overloading", "hairpinning", and "external source IP address and port" as defined in [RFC4787].
この文書では、ネットワークアドレスとDCCP接続のポート変換に必要なNATの状態を参照するために用語「NATマッピング」を使用しています。また、このドキュメントでは、「エンドポイント非依存のマッピング」、「アドレス依存マッピング」、「アドレスとポート依存マッピング」、「フィルタリングの振る舞い」、「エンドポイント非依存のフィルタリング」、「アドレス依存フィルタリング」、「アドレス用語を使用していますポート依存フィルタリング」、 『ポート割り当て』、 『[RFC4787]で定義されるように、ポート過負荷』、 『ヘアピン』、及び 『外部ソースIPアドレスとポート』。
This document applies to NAT devices that want to handle DCCP datagrams. It is not the intent of this document to deprecate the overwhelming majority of deployed NAT devices. These NATs are simply not expected to handle DCCP, so this memo is not applicable to them.
この文書では、DCCPデータグラムを処理するNATデバイスに適用されます。展開NATデバイスの圧倒的多数を廃止するには、このドキュメントの意図ではありません。これらのNATは、単にDCCPを処理するためには期待できないので、このメモはそれらには適用されませんされています。
Expected NAT behaviors applicable to DCCP connections are very similar to those applicable to TCP connections (with the exception of REQ-6 below). The following requirements are discussed and justified extensively in [RFC5382]. These justifications are not reproduced here for the sake of brevity.
DCCP接続に適用が期待NAT行動が（以下REQ-6を除く）のTCP接続に適用されるものと非常に似ています。以下の要件は[RFC5382]で議論し、広範囲に正当化されています。これらの正当化は、簡潔にするためにここに再現されていません。
In addition to the usual changes to the IP header (in particular, the IP addresses), NAT devices need to mangle:
IPヘッダに通常の変更（特に、IPアドレス）に加えて、NATデバイスは、マングルする必要があります。
o the DCCP source port for outgoing packets, depending on the NAT mapping,
発信パケットのためのDCCP送信元ポートO、NATマッピングに応じて、
o the DCCP destination port for incoming packets, depending on the NAT mapping, and
NATマッピングに応じて、着信パケットのDCCP宛先ポートO、および
o the DCCP checksum, to compensate for IP address and port number modifications.
DCCPチェックサムO、IPアドレスとポート番号の変更を補償します。
Because changing the source or destination IP address of a DCCP packet will normally invalidate the DCCP checksum, it is not possible to use DCCP through a NAT without dedicated support. Some NAT devices are known to provide "generic" transport-protocol support, whereby only the IP header is mangled. That scheme is not sufficient to support DCCP.
通常、DCCPチェックサムが無効になりますDCCPパケットの送信元または宛先IPアドレスを変更するので、専用のサポートなしでNATを通じてDCCPを使用することはできません。いくつかのNATデバイスは、IPヘッダのみがマングルされたとなる「汎用」のトランスポート・プロトコルのサポートを、提供することが知られています。そのスキームは、DCCPをサポートするのに十分ではありません。
A NAT uses a mapping to translate packets for each DCCP connection. A mapping is dynamically allocated for connections initiated from the internal side, and is potentially reused for certain subsequent connections. NAT behavior regarding when a mapping can be reused differs for different NATs, as described in [RFC4787].
NATは、各DCCP接続のパケットを変換するためのマッピングを使用しています。マッピングは、動的に内側から開始された接続のために割り当てられ、そして潜在的に特定の後続の接続のために再利用されます。 [RFC4787]で説明されるようにマッピングは、異なるNATのための異なる再利用することができる場合についてNAT振る舞い。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for DCCP.
REQ-1：NATは、DCCPのための「エンドポイント・独立マッピング」振る舞いを持たなければなりません。
REQ-2: A NAT MUST support all valid sequences of DCCP packets (defined in [RFC4340] and its updates) for connections initiated both internally as well as externally when the connection is permitted by the NAT. In particular, in addition to handling the DCCP 3-way handshake mode of connection initiation, A NAT MUST handle the DCCP simultaneous-open mode of connection initiation, defined in [RFC5596]. That mode updates DCCP by adding a new packet type: DCCP-Listen. The DCCP-Listen packet communicates the information necessary to uniquely identify a DCCP session. NATs may utilise the connection information (address, port, Service Code) to establish local forwarding state.
REQ-2：NATが開始された接続のためのすべての有効なDCCPパケットのシーケンス（[RFC4340]で定義され、そのアップデート）をサポートする必要があり、両方の内部ならびに外部接続がNATによって許可された場合。具体的には、接続開始のDCCP 3ウェイハンドシェイク処理モードに加えて、NATは、[RFC5596]で定義された接続開始のDCCP同時オープンモードを処理しなければなりません。 DCCP-聞く：このモードでは、新たなパケットタイプを追加することにより、DCCPを更新します。 DCCP-聞くパケットを一意にDCCPのセッションを識別するために必要な情報を伝達します。 NATはローカル転送状態を確立するための接続情報（アドレス、ポート、サービスコード）を利用することができます。
REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-independent filtering" behavior for DCCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-dependent filtering" behavior for DCCP.
REQ-3：アプリケーションの透明性が最も重要である場合には、NATは、DCCPのための「エンドポイント非依存のフィルタリング」の挙動を持っていることが推奨されます。より厳格なフィルタリング動作が最も重要であるならば、NATはDCCPのための「アドレス依存フィルタリング」の挙動を持っていることが推奨されます。
o The filtering behavior MAY be an option configurable by the administrator of the NAT.
Oフィルタリングの動作は、NATの管理者が設定オプションの可能性があります。
o The filtering behavior for DCCP MAY be independent of the filtering behavior for any other transport-layer protocol, such as UDP, UDP-Lite, TCP, and SCTP (Stream Control Transmission Protocol).
oをDCCPのフィルタリング動作は、UDP、UDP-Liteは、TCP、およびSCTP（ストリーム制御伝送プロトコル）のような他のトランスポート層プロトコル、のためのフィルタリング動作から独立していてもよいです。
REQ-4: A NAT MUST wait for at least 6 seconds from the reception of an unsolicited, inbound DCCP-Listen or DCCP-Sync packet before it may respond with an ICMP Port Unreachable error, an ICMP Protocol Unreachable error, or a DCCP-Reset. If, during this interval, the NAT receives and translates an outbound DCCP-Request packet for the connection, the NAT MUST silently drop the original unsolicited, inbound DCCP-Listen packet. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original DCCP-Listen unless the security policy forbids it.
REQ-4：それはICMPポート到達不能エラー、ICMPプロトコル到達不能エラー、またはDCCP-で応答することができる前に、NATは、迷惑DCCP-聞く着信またはDCCP同期パケットを受信してから少なくとも6秒間待たなければなりませんリセットします。この期間中に、NATは、接続のためのアウトバウンドDCCP-Requestパケットを受信して、変換し、場合、NATは静かに、元の迷惑、インバウンドDCCP-聞くパケットを廃棄しなければなりません。それ以外の場合は、NATは、セキュリティポリシーがそれを禁止しない限り、オリジナルのDCCPは、聞くためのICMPポート到達不能エラー（タイプ3、コード3）を送信すべきです。
The "established connection idle-timeout" for a NAT is defined as the minimum time a DCCP connection in the established phase must remain idle before the NAT considers the associated session a candidate for removal. The "transitory connection idle-timeout" for a NAT is defined as the minimum time a DCCP connection in the CLOSEREQ or CLOSING phases must remain idle before the NAT considers the associated session a candidate for removal. DCCP connections in the TIMEWAIT state are not affected by the "transitory connection idle-timeout".
NATのための「確立された接続アイドルタイムアウトは、」NATは関連するセッションに除去するための候補者を検討する前に確立フェーズにおけるDCCP接続がアイドル状態のままでなければならない最小の時間として定義されます。 NATのための「一時接続アイドルタイムアウトは、」NATは関連するセッションに除去するための候補者を検討する前に、CLOSEREQまたはCLOSING段階におけるDCCP接続がアイドル状態のままでなければならない最小の時間として定義されます。 TIMEWAIT状態でDCCP接続は、「一時的な接続アイドルタイムアウト」の影響を受けません。
REQ-5: If a NAT cannot determine whether the endpoints of a DCCP connection are active, it MAY abandon the session if it has been idle for some time. Where a NAT implements session timeouts, the default value of the "established connection idle-timeout" MUST be of 124 minutes or longer, and the default value of the "transitory connection idle-timeout" MUST be of 4 minutes or longer. A NAT that implements session timeouts may be configurable to use smaller values for the NAT idle-timeouts.
REQ-5：NATはDCCP接続のエンドポイントがアクティブであるかどうかを判断できない場合は、しばらくの間アイドル状態になっている場合、それはセッションを放棄することができます。 NATは、セッションタイムアウトを実装する場合、「確立された接続アイドルタイムアウト」のデフォルト値は124分以上でなければならず、そして「一時接続アイドルタイムアウト」のデフォルト値は4分以上でなければなりません。セッションタイムアウトを実装NATはNATアイドルタイムアウトの小さい値を使用するように構成してもよいです。
NAT behavior for handling DCCP-Reset packets or connections in the TIMEWAIT state is left unspecified.
TIMEWAIT状態にDCCP-リセットパケットまたは接続を処理するためのNAT動作は不定に残っています。
Contrary to TCP, DCCP is a loss-tolerant protocol. Therefore, modifying the payload of DCCP packets may present a significant additional challenge in maintaining any application-layer state needed for an Application Level Gateway (ALG) to function properly. Additionally, there are no known DCCP-capable ALGs at the time of writing this document.
TCPとは異なり、DCCPは、ロス・トレランスプロトコルです。したがって、DCCPパケットのペイロードを修正することは正しく機能するアプリケーションレベルゲートウェイ（ALG）のために必要な任意のアプリケーション層の状態を維持するのに重要な追加のチャレンジを提示してもよいです。また、この文書を書いている現時点では知られているDCCP対応のALGはありません。
REQ-6: If a NAT includes ALGs, these ALGs MUST NOT affect DCCP.
REQ-6：NATはのALGが含まれている場合、これらのALGはDCCPに影響してはいけません。
NOTE: This is not consistent with REQ-6 of [RFC5382].
注：これはREQ-6 [RFC5382]のと一致していません。
A list of general and UDP-specific NAT behavioral requirements are described in [RFC4787]. A list of ICMP-specific NAT behavioral requirements are described in [RFC5508]. The requirements listed
一般的およびUDP固有のNATの行動要件のリストは、[RFC4787]で説明されています。 ICMP特有のNATの行動要件のリストは、[RFC5508]で説明されています。記載された要件
below reiterate the requirements from these two documents that directly affect DCCP. The following requirements do not relax any requirements in [RFC4787] or [RFC5508].
下記直接DCCPに影響を与えるこれら二つの文書からの要求を繰り返します。次の要件は、[RFC4787]か[RFC5508]のいずれかの要件を緩和していません。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for DCCP.
REQ-7：NATはDCCPについては、「ポートのオーバーロード」の「ポートの割り当て」の動作を持ってはいけません。
REQ-8: A NAT MUST support "hairpinning" for DCCP. Furthermore, a NAT's hairpinning behavior MUST be of type "External source IP address and port".
REQ-8：NATはDCCPのための "ヘアピン" をサポートしなければなりません。さらに、NATのヘアピンの動作はタイプ「外部ソースのIPアドレスとポート」でなければなりません。
REQ-9: If a NAT translates DCCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
REQ-9：NATはDCCPを変換する場合は、ICMP宛先到達不能（タイプ3）メッセージを翻訳すべきです。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or DCCP connection for which the ICMP was generated.
REQ-10：ICMPメッセージの任意の並べ替えの領収書は、NATマッピングまたはICMPが生成されたDCCP接続を終了してはなりません。
DCCP supports partial checksum coverage. A NAT will usually need to perform incremental changes to the packet Checksum field, as for other IETF-defined protocols. However, if it needs to recalculate a correct checksum value, it must take the checksum coverage into account, as described in Section 9.2 of [RFC4340].
DCCPは、部分的なチェックサム適用範囲をサポートしています。 NATは、通常、他のIETF定義プロトコル用として、パケットのチェックサムフィールドに増分変更を実行する必要があります。それは正しいチェックサム値を再計算する必要がある場合は、[RFC4340]のセクション9.2で説明したようにしかし、それは、考慮にチェックサムカバレッジを取る必要があります。
REQ-11: If a NAT translates a DCCP packet with a valid DCCP checksum, it MUST ensure that the DCCP checksum is translated such that it is valid after the translation.
REQ-11：NATが有効なDCCPチェックサムとDCCPパケットを変換する場合は、DCCPのチェックサムが、それは、翻訳後に有効になるように翻訳されることを保証しなければなりません。
REQ-12: A NAT MUST NOT modify the value of the DCCP Checksum Coverage.
REQ-12：NATはDCCPチェックサムカバー範囲の値を変更してはいけません。
The Checksum Coverage field in the DCCP header determines the parts of the packet that are covered by the Checksum field. This always includes the DCCP header and options, but some or all of the application data may be excluded as determined on a packet-by-packet basis by the application. Changing the Checksum Coverage in the network violates the integrity assumptions at the receiver and may result in unpredictable or incorrect application behaviour.
DCCPヘッダのチェックサム・カバレッジ・フィールドは、チェックサムフィールドによって覆われているパケットの部分を決定します。これは、常にDCCPヘッダーとオプションを含むが、アプリケーションによって、パケットごとに決定されるように、アプリケーションデータの一部またはすべてが除外されてもよいです。ネットワーク内のチェックサムカバー範囲を変更すると、受信側で整合性の仮定に違反し、予測不可能なまたは不正なアプリケーションの動作になることがあります。
DCCP specifies a Service Code as a 4-byte value (32 bits) that describes the application-level service to which a client application wishes to connect [RFC4340].
DCCPは、クライアント・アプリケーションは、[RFC4340]に接続することを希望するアプリケーションレベルのサービスを記述する4バイト値（32ビット）などのサービスコードを指定します。
REQ-13: If a NAT translates a DCCP packet, it MUST NOT modify its DCCP Service Code value.
REQ-13：NATはDCCPパケットを変換する場合、それはそのDCCPサービスコードの値を変更してはいけません。
Further guidance on the use of Service Codes by middleboxes, including NATs, can be found in [RFC5595].
NATを含むミドルボックスによって、サービスコードの使用に関するさらなるガイダンスは、[RFC5595]で見つけることができます。
If the NAT device cannot be updated to support DCCP, DCCP datagrams can be encapsulated within a UDP transport header. Indeed, most NAT devices are already capable of handling UDP. This is however beyond the scope of this document.
NATデバイスは、DCCPをサポートするように更新することができない場合は、DCCPデータグラムは、UDPトランスポートヘッダ内にカプセル化することができます。実際、ほとんどのNATデバイスは、すでにUDPを取り扱うことができます。しかし、これは、このドキュメントの範囲を超えています。
[RFC4787] discusses security considerations for NATs that handle IP and unicast (UDP) traffic, all of which apply equally to this document. Security concerns specific to handling DCCP packets are discussed in this section.
[RFC4787]は、この文書にも同様に適用されるすべてのそれらのIPおよびユニキャスト（UDP）トラフィックを処理するNATのためのセキュリティの考慮事項について説明します。 DCCPパケットの処理に固有のセキュリティ上の懸念は、このセクションで説明されています。
REQ-1 and REQ-6 through REQ-13 do not introduce any new known security concerns.
REQ-13によるREQ-1およびREQ-6は、任意の新しい既知のセキュリティ上の懸念を導入していません。
REQ-2 does not introduce any new known security concerns. While a NAT may elect to keep track of some DCCP-specific, per-flow state (compared to UDP), it has no obligations to do so.
REQ-2は、任意の新しい既知のセキュリティ上の懸念を導入していません。 NATは、（UDPと比較して）いくつかのDCCP特有の、フローごとの状態を追跡することを選ぶかもしれないが、それはそうする一切の義務を持っていません。
REQ-3 allows a NAT to adopt either a more secure or a more application-transparent filtering policy. This is already addressed in [RFC4787] and [RFC5382].
REQ-3は、NATがより安全以上のアプリケーション・透明フィルタリングポリシーのいずれかを採用することができます。これは、すでに[RFC4787]と[RFC5382]で扱われています。
Similar to [RFC5382], REQ-4 of this document recommends that a NAT respond to unsolicited, inbound Listen and Sync packets with an ICMP error delayed by a few seconds. Doing so may reveal the presence of a NAT to an external attacker. Silently dropping the Listen makes it harder to diagnose network problems and forces applications to wait for the DCCP stack to finish several retransmissions before reporting an error. An implementer must therefore understand and carefully weigh the effects of not sending an ICMP error or rate-limiting such ICMP errors to a very small number.
[RFC5382]と同様に、REQ-4本書のは、NATが数秒遅れで表示ICMPエラーで迷惑、インバウンド聞くと同期パケットに応答することをお勧めします。そうすることで、外部の攻撃者にNATの存在を明らかにすることができます。サイレント聞くドロップすると、それは難しいDCCPスタックがエラーを報告する前に、いくつかの再送信を終了するのを待つために、ネットワークの問題と軍のアプリケーションを診断することができます。実装者は、したがって、理解し、慎重に非常に小さな数にICMPエラーや速度制限などICMPエラーを送信しないの効果を比較検討しなければなりません。
REQ-5 recommends that a NAT that passively monitors DCCP state keep idle sessions alive for at least 124 minutes or 4 minutes, depending on the state of the connection. To protect against denial-of-service attacks filling its state storage capacity, a NAT may attempt to actively determine the liveliness of a DCCP connection, or the NAT administrator could configure more conservative timeouts.
REQ-5は、受動DCCP状態を監視NATは、接続の状態に応じて、少なくとも124分又は4分生きているアイドル状態のセッションを続けることをお勧めします。その状態記憶容量を満たすサービス拒否攻撃から保護するために、NATは、積極的にDCCPコネクションの活気を決定しようとしたり、NAT管理者は、より保守的なタイムアウトを設定することができます。
The author would like to thank Gorry Fairhurst, Eddie Kohler, Dan Wing, Alfred Hoenes, Magnus Westerlund, Miguel Garcia, Catherine Meadows, Tim Polk, Lars Eggert, and Christian Vogt for their comments and help on this document.
作者は彼らのコメントのためにGorry Fairhurst、エディー・コーラー、ダン・ウィング、アルフレッドHoenes、マグヌスウェスター、ミゲル・ガルシア、キャサリン・メドウズ、ティムポーク、ラースエッゲルト、キリスト教フォークトに感謝し、この文書に手助けしたいと思います。
This memo borrows heavily from [RFC5382] by S. Guha (editor), K. Biswas, B. Ford, S. Sivakumar, and P. Srisuresh.
このメモはS.グハ（編集者）、K.ビスワス、B.フォード、S.シバクマー、およびP. Srisureshによって[RFC5382]から重く借り。
[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月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPのためのNAT行動要件"、BCP 148、RFC 5508、2009年4月。
[RFC5596] Fairhurst, G., "Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/ Middlebox Traversal", RFC 5596, September 2009.
[RFC5596] Fairhurst、G.、 "データグラム輻輳制御プロトコル（DCCP）NAT /ミドルトラバーサルを容易にするために、同時オープン技術"、RFC 5596、2009年9月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
、RFC 3424、2002年11月、 "ネットワークアドレス変換アクロス一方的な自己アドレス固定するためのIABの考慮事項（UNSAF）" [RFC3424] Daigle氏、L.とIAB、。
[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月。
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, September 2009.
[RFC5595] Fairhurst、G.、 "データグラム輻輳制御プロトコル（DCCP）サービスコード"、RFC 5595、2009年9月。
Author's Address
著者のアドレス
Remi Denis-Courmont VideoLAN project
レミデニス・Courmont VideoLANのプロジェクト
EMail: rem@videolan.org URI: http://www.videolan.org/
電子メール：rem@videolan.org URI：http://www.videolan.org/