Network Working Group G. Fairhurst
Request for Comments: 5596 University of Aberdeen
Updates: 4340 September 2009
Category: Standards Track
Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
データグラム輻輳制御プロトコル（DCCP）NAT /ミドルトラバーサルを容易にするために、同時オープンテクニック
Abstract
抽象
This document specifies an update to the Datagram Congestion Control Protocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., a Network Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near-simultaneous manner to establish necessary middlebox state.
この文書は、データグラム輻輳制御プロトコル（DCCP）、接続指向のデータグラムベースのトランスポートプロトコルに更新を指定します。更新はDCCP-聞くパケットのサポートを追加します。これは、ミドルボックス（例えば、ネットワークアドレスポート翻訳者またはファイアウォールの背後にあるDCCPサーバ）ピアリングエンドポイントがほぼ同時的に通信を開始する必要があり、必要なミドル状態を確立するためにを介して通信するためにDCCPアプリケーションを支援します。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3
1.2. DCCP NAT Traversal . . . . . . . . . . . . . . . . . . . . 4
1.3. Structure of This Document . . . . . . . . . . . . . . . . 4
2. Procedure for Near-Simultaneous-Open . . . . . . . . . . . . . 5
2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5
2.2. Protocol Method . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. DCCP-Listen Packet Format . . . . . . . . . . . . . . 6
2.2.2. Protocol Method for DCCP Server Endpoints . . . . . . 7
2.2.3. Protocol Method for DCCP Client Endpoints . . . . . . 11
2.2.4. Processing by Routers and Middleboxes . . . . . . . . 11
2.3. Examples of Use . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Repetition of DCCP-Listen . . . . . . . . . . . . . . 13
2.3.2. Optional Triggered Retransmission of DCCP-Request . . 14
2.4. Backwards Compatibility with RFC 4340 . . . . . . . . . . 16
3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 16
3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 17
3.1.1. Use of Sequence Numbers . . . . . . . . . . . . . . . 18
3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 18
3.3. Repetition of DCCP-Listen Packets . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Discussion of Existing NAT Traversal Techniques . . . 23
A.1. NAT Traversal Based on a Simultaneous-Request . . . . . . 24
A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 25
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is both datagram-based and connection-oriented. According to RFC 4340, DCCP servers establish connections by passively listening for incoming connection requests that are actively transmitted by DCCP clients. These asymmetric roles can cause problems when the server is 'inside' a middlebox, such as a Network Address Port Translation (NAPT), that only allows connection requests to be initiated from inside (e.g., due to port overloading) [RFC5597]. Host-based and network firewalls can also implement policies that lead to similar problems. This behaviour is currently the default for many firewalls.
データグラム輻輳制御プロトコル（DCCP）[RFC4340]は、データグラムベースとコネクション型の両方です。 RFC 4340によると、DCCPのサーバは受動的に積極的にDCCPクライアントによって送信された着信接続要求を聞くことによって接続を確立します。サーバーのみの接続要求は内部から開始することを可能にするようなネットワークアドレスポート変換（NAPT）として、ミドル、（例えば、原因ポートのオーバーロードへ）[RFC5597]「内部」の場合、これらの非対称の役割は、問題を引き起こす可能性があります。ホストベースとネットワークのファイアウォールでも同様の問題につながる政策を実施することができます。この動作は、現在、多くのファイアウォールのデフォルトです。
UDP can support middlebox traversal using various techniques [RFC4787] that leverage the connectionless nature of UDP and are therefore not suitable for DCCP. TCP supports middlebox traversal through the use of its simultaneous-open procedure [RFC5382]. The concepts of the TCP solution are applicable to DCCP, but DCCP cannot simply reuse the same methods (see Appendix A).
UDPはコネクションレスUDPの性質を活用する様々な技術[RFC4787]を使用して、ミドルトラバーサルをサポートし、したがって、DCCPには適していないことができます。 TCPは、その同時オープン手順[RFC5382]を使用して、ミドルトラバーサルをサポートしています。 TCPソリューションの概念はDCCPに適用されるが、DCCPは、単純に同じメソッドを（付録Aを参照）を再利用することはできません。
After discussing the problem space for DCCP, this document specifies an update to the DCCP state machine to offer native support that allows a DCCP client to establish a connection to a DCCP server that is inside one or more middleboxes. This reduces dependence on external aids such as data relay servers [STUN] by explicitly supporting a widely used principle known as 'hole punching'.
DCCPのための問題空間を議論した後、この文書には、DCCPクライアントは、1つまたは複数のミドルボックス内にあるDCCPサーバーへの接続を確立することを可能にするネイティブサポートを提供するためにDCCPステートマシンへの更新を指定します。これは、明示的に「パンチ」として知られ広く使われている原理をサポートすることにより、このようなデータ中継サーバ[STUN]などの外部補助への依存を軽減します。
The method requires only a minor change to the standard DCCP operational procedure. The use of a dedicated DCCP packet type ties usage to a specific condition, ensuring the method is inter-operable with hosts that do not implement this update or that choose to disable it (see Section 4).
この方法は、標準的なDCCP操作手順にわずかな変更が必要です。メソッドを確保特定条件に専用DCCPパケットタイプ関係の使用の使用は、（セクション4を参照）、この更新プログラムを実装するか、またはそれを無効にすることを選択しないホストと相互動作可能です。
This method is useful in scenarios when a DCCP server is located inside the perimeter controlled by a middlebox. It is relevant to both client/server and peer-to-peer applications, such as Voice over IP (VoIP), file sharing, or online gaming, and assists connections that utilise prior out-of-band signaling (e.g., via a well-known rendezvous server ([RFC3261], [H.323])) to notify both endpoints of the connection parameters ([RFC3235], [NAT-APP]).
DCCPサーバがミドルボックスによって制御境界の内側に位置している場合、この方法は、シナリオで有用です。それは、このようなボイスオーバーIP（VoIP）の、ファイル共有、またはオンラインゲームのようなクライアント/サーバとの両方のピア・ツー・ピア・アプリケーションに関連して、よく経由して、例えば（シグナリングアウト・オブ・バンド前に利用接続を支援します接続パラメータ（[RFC3235]、[NAT-APP]）の両方のエンドポイントに通知する-knownランデブーサーバ（[RFC3261]、[323]））。
The behavioural requirements for NAT devices supporting DCCP are described in [RFC5597]. A "traditional NAT" [RFC3022] that directly maps an IP address to a different IP address does not require the simultaneous-open technique described in this document.
DCCPをサポートするNATデバイスのための行動の要件は[RFC5597]で説明されています。直接別のIPアドレスにIPアドレスをマッピングし、「伝統的なNAT」[RFC3022]は、この文書で説明する同時オープン技術を必要としません。
The method is required when the DCCP server is positioned behind one or more NAPT devices in the path (hierarchies of nested NAPT devices are possible). This document refers to DCCP hosts located inside the perimeter controlled by one or more NAPT devices as having "private" addresses, and to DCCP hosts located in the global address realm as having "public" addresses.
DCCPサーバがパス内の1つまたは複数のNAPT装置の背後に配置されたときに方法が必要とされている（ネストされたNAPT装置の階層が可能です）。この文書では、「プライベート」アドレスを有するものとして、および「パブリック」アドレスを有するようにグローバルアドレス領域に配置DCCPホストへの1つ以上のNAPT装置によって制御される境界の内側に位置DCCPホストを指します。
DCCP NAT traversal is considered for the following scenarios:
DCCP NATトラバーサルは、次のシナリオが考慮されています。
A defining characteristic of traditional NAT devices [RFC3022] is that private hosts can connect to external hosts, but not vice versa. Hence, case (1) is possible using the protocol defined in [RFC4340]. A pre-configured, static NAT address map would allow outside hosts to establish connections in cases (2) and (3).
従来のNATデバイス[RFC3022]の決定的な特徴は、プライベートホストはその逆の外部ホストに接続するが、できないことです。したがって、ケース（1）[RFC4340]で定義されたプロトコルを使用して可能です。事前に設定、静的NATアドレス・マップは、外部ホストがケースに接続を確立することを可能にする（2）及び（3）。
A DCCP implementation conforming to [RFC4340] and a NAT device conforming to [RFC5597] would require a DCCP relay server to perform NAT traversal for cases (2) and (3).
[RFC4340]及び[RFC5597]に準拠したNATデバイスに適合するDCCP実装は、ケースに対してNATトラバーサルを実行するDCCP中継サーバを必要とする（2）及び（3）。
This document describes a method to support cases (2) and (3) without the aid of a DCCP relay server. This method updates RFC 4340 and requires the DCCP server to discover the IP address and the DCCP port that correspond to the DCCP client. Such signaling may be performed out-of-band (e.g., using the Session Description Protocol (SDP) [RFC4566]).
この文書では、ケースをサポートするための方法を記載する、（2）及び（3）DCCP中継サーバの助けなし。このメソッドの更新RFC 4340およびIPアドレスとDCCPクライアントに対応DCCPポートを発見するためにDCCPサーバが必要です。そのようなシグナリングを行うことができるアウト・オブ・バンド（例えば、セッション記述プロトコル（SDP）を使用して、[RFC4566]）。
For background information on existing NAT traversal techniques, please consult Appendix A.
既存のNATトラバーサル技術に関する背景情報については、付録Aを参照してください
The normative specification of the update is presented in Section 2. An informative discussion of underlying design decisions then follows in Section 3. Security considerations are provided in Section 4 and IANA considerations are provided in the concluding Section 5.
更新の規範的仕様は、第2節で提示された基本的な設計上の決定の有益な議論は、その後のセクションで3.セキュリティの考慮事項は、第4章で提供され、IANAの考慮事項は、結びのセクション5で提供されている以下の。
This section is normative and specifies the simultaneous-open technique for DCCP. It updates the connection-establishment procedures of [RFC4340].
このセクションは規範的であるとDCCP同時オープン技法を指定します。それは、[RFC4340]の接続確立手順を更新します。
The document uses the terms and definitions provided in [RFC4340]. Familiarity with this specification is assumed. In particular, the following convention from Section 3.2 of [RFC4340] is used:
文書は、[RFC4340]に設け用語および定義を使用します。この仕様に精通が想定されます。具体的には、[RFC4340]のセクション3.2から次の規則が使用されます。
Each DCCP connection runs between two hosts, which we often name DCCP A and DCCP B. Each connection is actively initiated by one of the hosts, which we call the client; the other, initially passive host is called the server.
各DCCP接続は、我々は多くの場合、積極的に私たちは、クライアントを呼び出すホスト、のいずれかによって開始され、それぞれの接続DCCP AとDCCP B.に名前を付ける2つのホスト間で実行されます。その他、最初にパッシブホストがサーバーと呼ばれています。
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]に記載されているように解釈されます。
The term "session" is used as defined in ([RFC2663], Section 2.3): DCCP sessions are uniquely identified by the 4-tuple of <source IP-address, source port, target IP-address, target port>.
DCCPセッション一意の4タプルによって識別され、<送信元IPアドレス、送信元ポート、ターゲットIPアドレス、ターゲットポート>：（[RFC2663]、セクション2.3）の中で定義されるような用語「セッション」が使用されます。
DCCP, in addition, introduces Service Codes, which can be used to identify different services available via the same port [RFC5595].
DCCPは、加えて、同じポート[RFC5595]を介して利用可能な異なるサービスを識別するために使用することができるサービスコードを、導入します。
This document adds a new DCCP packet type, DCCP-Listen, whose format is shown below.
この文書は、新しいDCCPパケットタイプを追加し、そのフォーマットを以下に示している、DCCP-聞きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |X| Reserved | Sequence Number High Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Low Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of a DCCP-Listen Packet
図1：DCCP-聞くパケットのフォーマット
o The Source Port field indicates the port on which the DCCP server is listening for a connection from the IP address that appears as the destination IP address in the packet.
ソースポートフィールドO DCCPサーバは、パケットの宛先IPアドレスとして表示されるIPアドレスからの接続をリッスンしているポートを示します。
o The Destination Port field indicates the port selected by a DCCP client to identify the connection. In this technique, this value must be communicated out-of-band to the server.
宛先ポートフィールドO接続を識別するために、DCCPクライアントによって選択されたポートを示します。この技術では、この値は、サーバにアウトオブバンド通信されなければなりません。
o The value of X MUST be set to 1. A DCCP-Listen packet is sent before a connection is established; therefore, there is no way to negotiate use of short sequence numbers ([RFC4340], Section 5.1).
Xの値は1 A、接続が確立される前にパケットが送信されるDCCP-リッスンに設定しなければなりませんOであり;従って、短いシーケンス番号（[RFC4340]、セクション5.1）の使用を交渉する方法はありません。
o The value of the Sequence Number field in a DCCP-Listen packet is not related to the DCCP sequence number used in normal DCCP messages (see Section 3 for a description of the use of the DCCP sequence number). Thus, for DCCP-Listen packets:
DCCP-聞くパケット内のシーケンス番号フィールドの値oを正常DCCPメッセージで使用DCCPシーケンス番号（DCCPシーケンス番号の使用の説明についてはセクション3を参照）に関連していません。したがって、DCCP-聞くパケット用：
* A DCCP server SHOULD set the high and low bits of the Sequence Number field to 0.
* DCCPサーバは、シーケンス番号フィールドのハイとローのビットを0に設定する必要があります。
* A DCCP client MUST ignore the value of the Sequence Number field.
* DCCPクライアントは、シーケンス番号フィールドの値を無視しなければなりません。
* Middleboxes MUST NOT interpret sequence numbers in DCCP-Listen packets.
*のMiddleboxesはDCCP-聞くパケットのシーケンス番号を解釈してはなりません。
o The Service Code field contains the Service Code value for which the server is listening for a connection (Section 8.1.2 of [RFC4340] and [RFC5595]). This value MUST correspond to a Service Code that the server is actually offering for a connection identified by the same source IP address and the same source port as that of the DCCP-Listen packet. Since the server may use multiple Service Codes, the specific value of the Service Code field needs to be communicated out-of-band, from client to server, prior to sending the DCCP-Listen packet, e.g., described using the Session Description Protocol (SDP) [RFC4566].
Oサービスコードフィールドには、サーバが接続（[RFC4340]のセクション8.1.2および[RFC5595]）をlistenしているサービスコード値が含まれています。この値は、サーバーが実際にDCCP-聞くパケットと同一の送信元IPアドレスと同じ送信元ポートによって識別される接続のために提供されていることをサービスコードに対応しなければなりません。サーバーが複数のサービスコードを使用することができますので、サービスコードフィールドの特定の値は、前例えば、DCCP-聞くパケットを送信し、クライアントからサーバに、アウト・オブ・バンド通信する必要があるため、（セッション記述プロトコルを用いて説明SDP）[RFC4566]。
o At the time of writing, there are no known uses of header options ([RFC4340], Section 5.8) with a DCCP-Listen packet. Clients MUST ignore all options in received DCCP-Listen packets. Therefore, feature values cannot be negotiated using a DCCP-Listen packet.
書き込み時には、O、DCCP-聞くパケットにヘッダオプション（[RFC4340]、セクション5.8）の既知の用途はありません。クライアントは受信DCCP-聞くパケットのすべてのオプションを無視しなければなりません。したがって、特徴値はDCCP-聞くパケットを使用してネゴシエートすることはできません。
o At the time of writing, there are no known uses of payload data with a DCCP-Listen packet. Since DCCP-Listen packets are issued before an actual connection is established, endpoints MUST ignore any payload data encountered in DCCP-Listen packets.
執筆時点でO、DCCP-聞くパケットとペイロードデータの使われてはいないはずです。実際の接続が確立される前に、DCCP-聞くパケットが発行されているので、エンドポイントはDCCP-聞くパケットで発生したペイロードデータを無視しなければなりません。
o The following protocol fields are required to have specific values:
以下のプロトコルフィールドが特定の値を持つことが要求されています○：
* Data Offset MUST have a value of five or more (i.e., at least 20 bytes).
* 5つ以上（すなわち、少なくとも20バイト）の値を有しなければならないオフセットデータ。
* CCVal MUST be zero (a connection has not been established).
* CCValがゼロでなければならない（接続が確立されていません）。
* CsCov MUST be zero (use of the CsCov feature cannot be negotiated).
* CsCovはゼロ（CsCov機能の使用をネゴシエートすることができない）でなければなりません。
* Type has the value 10, assigned by IANA to denote a DCCP-Listen packet.
*タイプDCCP-聞くパケットを示すためにIANAによって割り当てられた値10を有しています。
* X MUST be 1 (the generic header must be used).
* Xが1である必要があります（一般的なヘッダが使用されなければなりません）。
The remaining fields, including the "Res" and "Reserved" fields are specified by [RFC4340] and its successors. The interpretation of these fields is not modified by this document.
「RES」及び「予約」フィールドを含む残りのフィールドは、[RFC4340]及びその後継で指定されています。これらのフィールドの解釈は、このドキュメントでは変更されません。
This document updates Section 8.1 of [RFC4340] for the case of a fully specified DCCP server endpoint. The update modifies the way the server performs a passive-open.
この文書では、完全に指定されたDCCPサーバーのエンドポイントの場合は[RFC4340]のセクション8.1を更新します。更新サーバーがパッシブオープンを実行する方法を変更します。
Prior to connection setup, it is common for a DCCP server endpoint to not be fully specified: before the connection is established, a server usually specifies only the destination port and Service Code. (Sometimes the destination address is also specified.) This leaves the source address and source port unspecified. The endpoint only becomes fully specified after performing the handshake for an incoming connection. For such cases, this document does not update Section 8.4 of [RFC4340], i.e., the server adheres to the existing state transitions in the left half of Figure 2 (CLOSED => LISTEN => RESPOND).
接続が確立される前に、サーバは通常、唯一の宛先ポートとサービスコードを指定します：DCCPサーバーのエンドポイントが完全に指定されないようにするために接続設定に先立ち、それが一般的です。 （時には、送信先アドレスも指定されている。）これは、不特定の送信元アドレスと送信元ポートを残します。エンドポイントは、着信接続のためのハンドシェイクを実行した後に完全に指定となります。このような場合のために、このドキュメントは[RFC4340]のセクション8.4を更新しない、すなわち、サーバは、（CLOSED => =>応答するLISTEN）、図2の左半分に既存の状態遷移に付着します。
A fully specified DCCP server endpoint permits exactly one client, identified by source IP-address:port, destination IP-address:port, plus a single Service Code, to set up the connection. Such a server SHOULD perform the actions and state transitions shown in the right half of Figure 2 and specified below.
完全に指定されたDCCPサーバエンドポイント正確に一つのクライアント、送信元IPアドレスで識別される許可証：ポート、宛先IPアドレス：ポート、プラス単一サービスコードは、接続を設定します。そのようなサーバは、図2の右半分に示され、以下に指定されたアクションと状態遷移を実行しなければなりません。
unspecified remote +--------+ fully specified remote
+---------------------| CLOSED |---------------------+
| +--------+ send DCCP-Listen |
| |
v v
+--------+ timeout +---------+
| LISTEN | +---+-----------| INVITED |
+--------+ | | +---------+
| | | 1st / 2nd ^ |
| more than 2 | | retransm. | | receive
| retransmissions | +-------------+ | Request
| | resend Listen v
| | +---------+
| +-------------->| LISTEN1 |
| +---------+
| |
| receive Request +---------+ receive Request* |
+------------------->| RESPOND |<--------------------+
send Response +---------+ send Response
* Note: The case of a server that responds to a DCCP-Request in the INVITED state, transitions to the LISTEN1 state, and then immediately transitions to the RESPOND state does not require reception of an additional DCCP-Request packet.
*注：その後、招待状態のDCCP-要求に応答するサーバーの場合、LISTEN1状態に遷移し、すぐに応答状態に遷移が追加DCCP-Requestパケットの受信を必要としません。
Figure 2: Updated State Transition Diagram for DCCP-Listen
図2：更新された状態遷移図DCCP-聞くため
This diagram introduces two additional DCCP server states in addition to those listed in Section 4.3 of [RFC4340]:
この図は、[RFC4340]のセクション4.3に記載されたものに加えて二つの追加DCCPサーバーの状態が導入されています。
INVITED The INVITED state is associated with a specific DCCP connection and represents a fully specified server socket in the listening state that is generating DCCP-Listen packets towards the client.
招待状態は、特定のDCCP接続に関連し、クライアントに向けてDCCP-聞くパケットを生成しているリスニング状態で完全に指定されたサーバソケットを表している招待。
LISTEN1 The LISTEN1 state is associated with a specific DCCP connection and represents a fully specified server socket in the passive listening state that will not generate further DCCP-Listen packets towards the client.
LISTEN1ザ・LISTEN1状態は、特定のDCCP接続に関連し、クライアントに向けて、さらにDCCP-聞くパケットを生成しません受動的なリスニング状態で完全に指定されたサーバソケットを表しています。
A fully specified server endpoint performs a passive-open from the CLOSED state by inviting the remote client to connect. This is performed by sending a single DCCP-Listen packet to the specified remote IP-address:port, using the format specified in Section 2.2.1. The figure below provides pseudocode describing the packet processing in the INVITED state. This processing step follows Step 2 in Section 8.5 of [RFC4340]).
完全に指定されたサーバエンドポイントが接続するリモートクライアントを招待することによって閉状態からパッシブオープンを行います。 2.2.1節で指定された形式を使用して、ポート：これは、指定されたリモートIPアドレスにシングルDCCP-聞くパケットを送信することにより行われます。下図招待状態におけるパケット処理を説明する擬似コードを提供します。この処理ステップは、[RFC4340]のセクション8.5のステップ2に続きます）。
The INVITED state is, like LISTEN, a passive state, characterised by waiting in the absence of an established connection. If the server endpoint in the INVITED state receives a DCCP-Request that matches the set of bound ports and addresses, it transitions to the LISTEN1 state and then immediately transitions to the RESPOND state, where further processing resumes as specified in [RFC4340].
招待状態、聞くように、確立された接続が存在しない状態で待機することを特徴と受動状態、です。招待状態のサーバエンドポイントが結合されたポートとアドレスのセットと一致DCCP-Requestを受信した場合、それはLISTEN1状態に遷移した後すぐに、[RFC4340]で指定されるように、さらなる処理が再開RESPOND状態に遷移します。
The server SHOULD repeat sending a DCCP-Listen packet while in the INVITED state, at a 200-millisecond interval with up to at most 2 repetitions (Section 3 discusses this choice of time interval). If the server is still in the INVITED state after a further period of 200ms following transmission of the third DCCP-Listen packet, it SHOULD progress to the LISTEN1 state.
サーバーは、最大2回繰り返し（第3節議論した時間間隔のこの選択）までで200ミリ秒間隔で、招待状態の間、DCCP-聞くパケットを送信繰り返す必要があります。サーバは、第三のDCCP-聞くパケットの送信次の200msのさらなる期間の後招待状態のままである場合、それはLISTEN1状態に進行するべきです。
Fully specified server endpoints SHOULD treat ICMP error messages received in response to a DCCP-Listen packet as "soft errors" that do not cause a state transition. Reception of an ICMP error message as a result of sending a DCCP-Listen packet does not necessarily indicate a failure of the following connection request, and therefore should not result in a server state change. This reaction to soft errors exploits the valuable feature of the Internet that, for many network failures, the network can be dynamically reconstructed without any disruption of the endpoints.
完全に指定されたサーバーのエンドポイントは、状態遷移を起こさない「ソフトエラー」としてDCCP-聞くパケットに応答して受信ICMPエラーメッセージを扱うべきです。 DCCP-聞くパケットを送信した結果としてICMPエラーメッセージの受信は、必ずしも次の接続要求の失敗を示すものではないので、サーバ状態変化をもたらすべきではありません。ソフトエラーに対するこの反応は、多くのネットワーク障害のために、ネットワークが動的エンドポイントの任意の中断することなく再構成することができる、インターネットの貴重な機能を活用します。
Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A DCCP server in the LISTEN, INVITED, or LISTEN1 states MAY generate a
サーバーのエンドポイントは、すべての着信DCCP-聞くパケットを無視すべきです。 LISTEN、招待、またはLISTEN1状態におけるDCCPサーバが生成してもよい（MAY）
DCCP-Reset packet (Code 7, "Connection Refused") in response to a received DCCP-Listen packet. This DCCP-Reset packet is an indication that two servers are simultaneously awaiting connections on the same port.
DCCP-リセットパケット受信DCCP-聞くパケットに応じて（コード7は、「接続が拒否されました」）。このDCCP-リセットパケットは、2台のサーバーが同時に同じポートで接続を待っていることの指標です。
Further details on the design rationale are discussed in Section 3.
設計根拠に関する詳細については、第3節で議論されています。
The figure below provides pseudocode describing the packet processing in the INVITED state. This processing step follows Step 2 in Section 8.5 of RFC 4340 [RFC4340].
下図招待状態におけるパケット処理を説明する擬似コードを提供します。この処理ステップは、RFC 4340 [RFC4340]のセクション8.5のステップ2に続きます。
Step 2a: Process INVITED state
If S.state == INVITED,
/* State only entered for fully specified server endpoints */
/* on entry S will have been set to a socket */
If P.type == Request
/* Exit INVITED state and continue to process the packet */
S.state = LISTEN1
Continue with S.state := LISTEN1
Otherwise,
If P.type == Listen
/* The following line is optional */
Generate Reset(Connection Refused)
/* Otherwise, drop packet and return */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Step 2b: Process LISTEN1 state
If S.state == LISTEN1,
/* State only entered for fully specified server endpoints */
/* Follows receipt of a Response packet */
/* or sending third Listen packet (after timer expiry) */
If P.type == Request,
S.state = RESPOND
Choose S.ISS (initial seqno) or set from Init Cookies
Initialize S.GAR := S.ISS
Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies
Continue with S.state == RESPOND
/* A Response packet will be generated in Step 11 */
Otherwise,
If P.type == Listen
/* The following line is optional */
Generate Reset(Connection Refused)
/* Otherwise, drop packet and return */
Otherwise,
Generate Reset(No Connection) unless P.type == Reset
Figure 3: Updated DCCP Pseudocode for INVITED and LISTEN1 States
図3：招待され、LISTEN1国のために更新されたDCCP擬似コード
This document updates Section 8.1.1 of [RFC4340] by adding the following rule for the reception of DCCP-Listen packets by clients:
この文書では、クライアントがDCCP-聞くパケットの受信のために以下のルールを追加することによって、[RFC4340]のセクション8.1.1を更新します。
Endpoints are required to ignore any header options or payload data encountered in DCCP-Listen packets (Section 2.2.1) and hence do not provide meaningful communication to a client. A client in any state MUST silently discard any received DCCP-Listen packet, unless it implements the optional procedure defined in the following section.
エンドポイントはDCCP-聞くパケット（セクション2.2.1）に発生したヘッダ・オプション又はペイロードデータを無視し、従ってクライアントに意味のある通信を提供しない要求されています。どのような状態にあるクライアントは黙っいずれかが、それは次のセクションで定義されたオプションの手順を実装していない限り、パケットをDCCPは、聞く受信捨てなければなりません。
This section describes an optional optimisation at the client that can allow the client to avoid having to wait for a timeout following a dropped DCCP-Request. The operation requires clients to respond to reception of DCCP-Listen packets when received in the REQUEST state. DCCP-Listen packets MUST be silently discarded in all other states.
このセクションでは、クライアントが落ちDCCP-Requestを、次のタイムアウトを待つことを回避できるようにすることができ、クライアントのオプションの最適化について説明します。操作はREQUEST状態で受信したときにDCCP-聞くパケットの受信に対応するために、クライアントが必要です。パケットは黙って他のすべての州で捨てなければなりませんDCCPは、聞いてください。
A client implementing this optimisation MAY immediately perform a retransmission of a DCCP-Request following the reception of the first DCCP-Listen packet. The retransmission is performed in the same manner as a timeout in the REQUEST state [RFC4340]. A triggered retransmission SHOULD result in the client increasing the exponential-backoff timer interval.
この最適化を実装するクライアントは、すぐに最初のDCCP-聞くパケットの受信、次のDCCP-要求の再送信を行うことができます。再送が要求状態[RFC4340]でタイムアウトと同様に行われます。トリガーの再送信は、指数バックオフタイマー間隔を増やし、クライアントを生じるはずです。
Note that a path delay greater than 200ms will result in multiple DCCP-Listen packets arriving at the client before a DCCP-Response is received. Clients MUST therefore perform only one such retransmission for each DCCP connection. This requires maintaining local state (e.g., one flag per connection).
DCCP-応答が受信される前に、複数のクライアントに到着するパケットをDCCPは、聞くには200msよりも大きいパスの遅延が発生することに注意してください。クライアントは、したがって、各DCCP接続のために一つだけ、このような再送信を実行しなければなりません。これは、ローカル状態（例えば、接続ごとに1つのフラグ）を維持する必要があります。
Implementors and users of this optional method need to be aware that host timing or path reordering can result in a server receiving two DCCP-Requests (i.e., the server sending one unnecessary packet). This would, in turn, trigger a client to send a second corresponding DCCP-Response (also unnecessary). These additional packets are not expected to modify or delay the DCCP open procedure [RFC4340].
この任意の方法の実装およびユーザが並び替えホストタイミングまたは経路は、2つのDCCP - 要求（即ち、サーバー一個の不要なパケットを送信する）を受信するサーバをもたらすことができることを認識する必要があります。これは、順番に、第2の対応DCCP-応答を（も不要）送信するためにクライアントをトリガします。これらの追加のパケットはDCCPオープン手順[RFC4340]を変更したり、遅らせることが期待されていません。
Section 2.3.2 provides examples of the use of triggered retransmission.
セクション2.3.2は、トリガーの再送信の使用例を示します。
DCCP-Listen packets do not require special treatment and should thus be forwarded end-to-end across Internet paths, by routers and middleboxes alike.
DCCP-聞くパケットは、特別な処理を必要としないので、同様にルータやミドルボックスによって、インターネットパスの間でエンドツーエンドに転送する必要があります。
Middleboxes may utilise the connection information (address, port, Service Code) to establish local forwarding state. The DCCP-Listen packet carries the necessary information to uniquely identify a DCCP session in combination with the source and destination addresses (found in the enclosing IP header), including the DCCP Service Code value [RFC5595]. The processing of the DCCP-Listen packet by NAT devices is specified in [RFC5597].
Middleboxesは、ローカル転送状態を確立するための接続情報（アドレス、ポート、サービスコード）を利用することができます。 DCCPは、聞くパケットを一意DCCPサービスコード値[RFC5595]を含む（囲むIPヘッダにある）送信元アドレスと宛先アドレスと組み合わせてDCCPセッションを識別するために必要な情報を運びます。処理[RFC5597]で指定されたNATデバイスによってパケットをDCCPは、聞きます。
In the examples below, DCCP A is the client and DCCP B is the server. A middlebox device (NAT/Firewall), NA, is placed before DCCP A, and another middlebox, NB, is placed before DCCP B. Both NA and NB use a policy that permits DCCP packets to traverse the device for outgoing links, but only permits incoming DCCP packets when a previous packet has been sent out for the same connection.
以下の実施例では、DCCP Aはクライアントであり、DCCP Bはサーバです。ミドル装置（NAT /ファイアウォール）、NAは、DCCP Aの前に配置され、そして別のミドル、NBは、発信リンクのための装置を横断するDCCPパケットを許可するポリシーを使用DCCP Bの両方NA及びNBの前に配置され、のみ前回のパケットが同じ接続のために送り出されたの着信DCCPのパケットを許可します。
In the figure below, DCCP A and DCCP B decide to communicate using an out-of-band mechanism (in this case, labelled SDP), whereupon the client and server are started. DCCP B actively indicates its listening state by sending a DCCP-Listen message. This fulfills the requirement of punching a hole in NB (also creating the binding to the external address and port). This message is dropped by NA since no hole exists there yet. DCCP A initiates a connection by entering the REQUEST state and sending a DCCP-Request. (It is assumed that if NA were a NAT device, then this would also result in a binding that maps the pinhole to the external address and port.) The DCCP-Request is received by DCCP B, via the binding at NB. DCCP B transmits the DCCP-Response and connects through the bindings now in place at NA and NB.
以下の図では、DCCP AとDCCP Bが起動され、クライアントとサーバのところ、（SDPを標識し、この場合には、）アウトオブバンドメカニズムを使用して通信することを決定します。 DCCP Bは、積極的にDCCP-聞くメッセージを送信することにより、そのリスニング状態を示しています。これは、（外部アドレスとポートにバインドを作成）NBに穴をパンチングの要件を満たします。何の穴がまだ存在しないため、このメッセージは、NAによってドロップされます。 DCCP Aは、要求状態に入るとDCCP-Requestを送信することにより接続を開始します。 （NAがNATデバイスであれば、これはまた、外部アドレス・ポートにピンホールをマップする結合をもたらすことが想定される。）DCCP-要求がNBでの結合を介して、DCCP Bによって受信されます。 DCCP BはDCCP-応答を送信し、NA及びNBに代えて、今のバインディングを介して接続されています。
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| SDP --> |--+-+----+-+->| | State = INVITED
| | | |X---+-+--|<-- DCCP-Listen |
|(State=REQUEST) | | | | | | |
|DCCP-Request --> |--+-+----+-+->| |
|(State=PARTOPEN) | <+-+----+-+--|<-- DCCP-Response| State = RESPOND
|DCCP-Ack --> |--+-+----+-+> | |
| | | | | | | |
| | | | | | | |
|DCCP-Data --> |--+-+----+-+->| | State = OPEN
+-----------------+ +-+ +-+ +-----------------+
Figure 4: Event Sequence When the Server Is Started Before the Client
図4：イベントシーケンスサーバは、クライアントが開始される前
This section examines the effect of not receiving the DCCP-Request.
このセクションでは、DCCP-Requestを受信していないの効果を調べます。
The figure below shows the sequence of packets where the DCCP server enters the INVITED state after reception of out-of-band signaling (e.g., SDP). The key timer operations at the client and server are respectively shown on the left and right of the diagram. It considers the case when the server does not receive a DCCP-Request within the first 600ms (often the request would be received within this interval).
以下の図は、DCCPサーバがアウトオブバンドシグナリングの受信（例えば、SDP）の後に招待状態となるパケットのシーケンスを示しています。クライアントとサーバのキータイマー操作は、それぞれの図の左側と右側に表示されます。これは、サーバーが最初に600msの（多くの場合、リクエストはこの期間内に受信されます）内のDCCP-Requestを受信しない場合を考えます。
The repetition of DCCP-Listen packets may be implemented using a timer. The timer is restarted with an interval of 200ms when sending each DCCP-Listen packet. It is cancelled when the server leaves the INVITED state. If the timer expires after the first and second transmission, it triggers a transmission of another DCCP-Listen packet. If it expires after sending the third DCCP-Listen packet, the server leaves the INVITED state to enter the LISTEN1 state (where it passively waits for a DCCP-Request).
DCCP-聞くパケットの繰り返しは、タイマーを使用して実施することができます。各DCCP-聞くパケットを送信する場合、タイマーは200ミリ秒の間隔で再開されます。サーバが招待状態を離れたときに解除されます。タイマーは、第1および第2の送信後に期限切れになった場合、それは別のDCCP-聞くパケットの送信を開始します。それは第三のDCCP-聞くパケットを送信した後に満了した場合、サーバは、（それが受動的にDCCP-要求を待つ場合）LISTEN1状態に入るために招待状態を残します。
DCCP A DCCP B
------ NA NB ------
+----+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
| -->|--+-+----+-+--|--> SDP |
| | | | | | | | State = INVITED
| | | | | | | |
| | | |X---+-+--|<-- DCCP-Listen | Timer Starts
| | | | | | | | |
DCCP-Request | -->|--->+--X | | | (dropped) | |
Timer Starts | | | | | | | | |
| | | | | | | | | 1st Timer Expiry
| | |<-+-+----+++--|<-- DCCP-Listen |
| | | | | | | | | Timer Starts
| | | | | | | | | |
| | | | | | | | | 2nd Timer Expiry
| | | | | | | | |
| | |<-+-+----+-+--|<-- DCCP-Listen | Timer Starts
| | | | | | | | | |
| | | | | | | | | 3rd Timer Expiry
| | | | | | | | |
| | | | | | | | | State = LISTEN1
| ~ ~ ~ ~ ~ ~ ~ ~
| | | | | | | | |
Timer Expiry | -->|--+-+----+-+--|--> DCCP-Request |
| | | | | | | | State = RESPOND
| <--|--+-+----+-+--|<-- DCCP-Response|
+----+ +-+ +-+ +-----------------+
Figure 5: Repetition of the DCCP-Listen Packet
図5：DCCP-聞くパケットの繰り返し
The following figure illustrates a triggered retransmission. In this figure, the first DCCP-Listen is assumed to be lost in the network (e.g., does not open a pinhole at NB). A later DCCP-Request is also not received (perhaps as a side effect of the first loss). After 200ms, the DCCP-Listen packet is retransmitted and correctly received. This triggers the retransmission of the DCCP-Request, which, when received, results in a corresponding DCCP-Response.
次の図は、トリガーされた再送信を示しています。この図では、第一のネットワーク（例えば、NBでのピンホールを開けない）で失われているものとするDCCPは、聞きます。後DCCP-要求は、（おそらく最初の損失の副作用として）受信されていません。 200msの後、DCCP-聞くパケットを再送し、正しく受信されます。これは、受信された、DCCP - 要求の再送をトリガする対応DCCP-応答をもたらします。
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP |--+-+----+-+->| | State = INVITED
|(State= REQUEST) | | | | | | |
| | | | | |X-|<-- DCCP-Listen |
|DCCP-Request --> |--+-+---X| | | |
| | <+-+----+-+--|<-- DCCP-Listen |(retransmit)
| | | | | | | |
|DCCP-Request --> |--+-+----+-+->| | State = RESPOND
| (Triggered) | | | | | | |
| |<-+-+----+-+--|<-- DCCP-Response|
|(State= PARTOPEN)| | | | | | |
|DCCP-Ack --> |--+-+----+-+->| | State = OPEN
+-----------------+ +-+ +-+ +-----------------+
Figure 6: Example Showing a Triggered DCCP-Request
図6：例トリガーDCCP-Requestを表示
The figure below illustrates the sequence of packets exchanged when a DCCP-Listen and DCCP-Request are processed out of order. Reception of the DCCP-Listen packet by the client triggers retransmission of the DCCP-Request. The server responds to the first DCCP-Request and enters the RESPOND state. The server subsequently responds to the second DCCP-Request with another DCCP-Response, which is ignored by the client (already in the PARTOPEN state).
下の図は、DCCP-聞くとDCCP-Requestが順不同で処理されたときに、パケットの順序を入れ替え示しています。クライアントによるDCCP-聞くパケットの受信は、DCCP-要求の再送信をトリガします。サーバーは、最初DCCP-要求に応答して応答状態になります。サーバーは、その後、（すでにPARTOPEN状態にある）クライアントによって無視されている別のDCCP-応答、を有する第二DCCP-要求に応答します。
DCCP A DCCP B
------ NA NB ------
+-----------------+ +-+ +-+ +-----------------+
| | | | | | | | State = CLOSED
|SDP |--+-+----+-+->| | State = INVITED
|(State = REQUEST)| | | | | | |
|DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Listen |
| | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Response| State = RESPOND
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| |<-+-+- -+-+->| |
|(State= PARTOPEN)| | | | | | |
|DCCP-Ack --> |--+-+- -+-+--|<-- DCCP-Response|
| (Triggered) | | | \/ | | | |
| | | | /\ | | | |
| (Ignored) |<-+-+- -+-+->| | State = OPEN
| | | | | | | |
+-----------------+ +-+ +-+ +-----------------+
Figure 7: Example Showing an Unnecessary Triggered DCCP-Request
図7：不要なトリガDCCP-Requestを示す一例
No changes are required if a DCCP client conforming to this document communicates with a DCCP server conforming to [RFC4340].
この文書に準拠したDCCPクライアントは[RFC4340]に準拠したDCCPサーバーと通信する場合変更する必要はありません。
If a client implements only [RFC4340], an incoming DCCP-Listen packet would be ignored due to step 1 in Section 8.1 of [RFC4340], which at the same time also conforms to the behaviour specified by this document.
クライアントのみ[RFC4340]を実装している場合は、着信DCCP-聞くパケットが同時にまた、この文書で指定された動作に準拠した、[RFC4340]の8.1節の1ステップによる無視されます。
This document further does not modify communication for any DCCP server that implements a passive-open without fully binding the addresses, ports, and Service Codes to be used. The authors therefore do not expect practical deployment problems with existing, conformant DCCP implementations.
この文書では、さらに、完全に使用されるアドレス、ポート、およびサービスコードを結合することなく、パッシブオープンを実装するDCCPサーバの通信を変更しません。著者はこのため、既存の、準拠DCCP実装と実用的な展開の問題を期待しないでください。
This is an informative section that reviews the rationale for the design of this method.
これは、この方法の設計のための理論的根拠をレビュー有益セクションです。
The DCCP-Listen packet specified in Section 2.2.1 has the same format as the DCCP-Request packet ([RFC4340], Section 5.1), the only difference is in the value of the Type field. The usage, however, differs. The DCCP-Listen packet serves as an advisory message, not as part of the actual connection setup: sequence numbers have no meaning, and no payload can be communicated.
セクション2.2.1で指定されたDCCP-聞くパケットは、唯一の違いは、Typeフィールドの値であり、DCCP-Requestパケット（[RFC4340]、セクション5.1）と同じフォーマットを有します。使用方法は、しかし、異なっています。 DCCP-聞くパケットは、補助メッセージとしてではなく、実際の接続設定の一部として機能：シーケンス番号は意味を持たず、いかなるペイロードが連通することができません。
A DCCP-Request packet could, in theory, also have been used for the same purpose. The following arguments were against this:
DCCP-Requestパケットは、理論的には、同じ目的のために使用されたかもしれません。次の引数は、これに反対しました。
The first problem was that of semantic overloading: the DCCP-Request defined in [RFC4340] serves a well-defined purpose, being the initial packet of the 3-way handshake. Additional use in the manner of a DCCP-Listen packet would have required DCCP processors to have two different processing paths: one where a DCCP-Request was interpreted as part of the initial handshake, and another where the same packet was interpreted as an indication of an intention to accept a new connection. This would complicate packet processing in hosts and, in particular, stateful middleboxes (which may have restricted computational resources).
最初の問題は、意味論的過負荷であった：[RFC4340]で定義されたDCCPリクエストは3ウェイハンドシェイクの最初のパケットであり、明確に定義された目的を果たします。 DCCP-聞くパケットのように付加的な使用は、二つの異なる処理経路を有するようにDCCPプロセッサを必要としています：DCCP-Requestが初期ハンドシェークの一部として解釈されたものを、同一のパケットを示すものとして解釈された場合、別の新しい接続を受け入れる意向。これは、ホストと（計算リソースが制限されている場合があります）、具体的には、ステートフルミドルボックスでパケット処理が複雑になります。
The second problem is that a client receiving a DCCP-Request from a server could generate a DCCP-Reset packet if it had not yet entered the REQUEST state (step 7 in Section 8.5 of [RFC4340]). The method specified in this document lets client endpoints ignore DCCP-Listen packets. Adding a similar rule for the DCCP-Request packet would have been cumbersome: clients would not have been able to distinguish between a DCCP-Request packet meant to indicate an intention to accept a new connection and a genuinely erratic connection initiation.
第二の問題は、それがまだ要求状態（[RFC4340]のセクション8.5でステップ7）を入力しなかった場合、サーバからDCCP-Requestを受信したクライアントは、DCCP - リセットパケットを生成することができるということです。この文書で指定されたメソッドは、クライアントのエンドポイントがDCCP-聞くパケットを無視することができます。 DCCP-Requestパケットのための同様のルールを追加すると、面倒だったでしょう：クライアントは、新しい接続と本当に不安定な接続開始を受け入れる意思を示すことを意味DCCP-Requestパケットを区別することはできなかったでしょう。
The third problem is similar and refers to a client receiving the indication after having itself sent a (connection-initiation) DCCP-Request. Step 7 in Section 8.5 of [RFC4340] requires the client to reply to a DCCP-Request from the server with a DCCP-Sync packet. Since sequence numbers are ignored for this type of message, additional and complex processing would become necessary: either to ask the client not to respond to a DCCP-Request when the request is used as an indication, or to ask middleboxes and servers to ignore DCCP-Sync packets generated in response to DCCP-Request packets that are used as indications. Furthermore, since no initial sequence numbers have been negotiated at this stage, sending a DCCP-SyncAck would not be meaningful.
第3の問題は類似しており、それ自体が（接続開始）DCCP-Requestを送信した後指示を受信するクライアントを指します。 [RFC4340]のセクション8.5のステップ7はDCCP-Syncのパケットを使用してサーバからDCCP-要求に応答するクライアントが必要です。いずれかの要求が指標として使用されたときにDCCP-要求に応答しないクライアントに依頼する、またはDCCPを無視するミドルボックスとサーバーを依頼する：シーケンス番号は、メッセージのこのタイプでは無視されているので、追加で複雑な処理が必要になります指標として使用されているDCCP-Requestパケットに応答して生成-syncパケット。さらに、以来、何の初期シーケンス番号は意味がないでしょうDCCP-SyncAckを送る、この段階で交渉されていません。
The use of a separate packet type therefore allows simpler and clearer processing.
別のパケット型の使用は、したがって、単純かつ明確処理を可能にします。
Although the DCCP-Listen Sequence Number fields are ignored, they have been retained in the DCCP-Listen packet header to reuse the generic header format from Section 5.1 of [RFC4340].
DCCP-聞くシーケンス番号フィールドは無視されますが、それらは[RFC4340]のセクション5.1から一般的なヘッダフォーマットを再利用するためにDCCP-聞くパケットのヘッダに保持されています。
DCCP assigns a random initial value to the sequence number when a DCCP connection is established [RFC4340]. However, a sender is required to set this value to zero for a DCCP-Listen packet. Both clients and middleboxes are also required to ignore this value.
DCCPはDCCP接続は[RFC4340]を確立されたシーケンス番号とランダムな初期値を代入します。しかし、送信者がDCCP-聞くパケットのためにこの値をゼロに設定する必要があります。両方のクライアントとミドルボックスは、この値を無視する必要があります。
The rationale for ignoring the Sequence Number fields of DCCP-Listen packets is that, at the time the DCCP-Listen is exchanged, the endpoints have not yet entered connection setup: the DCCP-Listen packet is sent while the server is still in the passive-open (INVITED) state, i.e., it has not yet allocated state, other than binding to the client's IP-address:port and Service Code.
DCCP-聞いたパケットのシーケンス番号フィールドを無視する根拠が一度にDCCPは、聞く、ということであるが交換され、エンドポイントはまだ接続設定を入力していない：サーバーがパッシブにまだある間、DCCP-聞くパケットが送信されますポートおよびサービスコード：-open（招待）状態、すなわち、それはまだ、クライアントのIPアドレスへの結合以外の状態を、割り当てられていません。
A DCCP server should by default permit generation of DCCP-Listen packets. Since DCCP-Listen packets solve a particular problem with NAT and/or firewall traversal, the generation of DCCP-Listen packets on passive sockets is tied to a condition (binding to a remote address and Service Code that are both known a priori) to ensure this does not interfere with the general case of "normal" DCCP connections (where client addresses are generally not known in advance).
DCCPサーバはDCCP-聞くパケットのデフォルトの許可世代によって必要があります。 DCCP-聞くパケットは特定のNATに問題および/またはファイアウォールトラバーサルを解決するため、受動ソケットにDCCP-聞くパケットの生成を確実にするために（両方先験的に知られているリモートアドレスとサービスコードとの結合）状態に関連付けられていこれは、（クライアントアドレスは、一般的に事前に知られていない）「ノーマル」DCCPコネクションの一般的なケースに干渉しません。
In the TCP world, the analogue is a transition from LISTEN to SYN_SENT by virtue of sending data: "A fully specified passive call can be made active by the subsequent execution of a SEND" ([RFC0793], Section 3.8). Unlike TCP, this update does not perform a role change from passive to active. Like TCP, DCCP-Listen packets are only sent by a DCCP-server when the endpoint is fully specified (Section 2.2).
「完全に指定された受動的呼がSENDのその後の実行によりアクティブにすることができる」（[RFC0793]、セクション3.8）：TCPの世界では、アナログは、データを送信することによってSYN_SENTを聞くからの遷移です。 TCPとは異なり、今回のアップデートでは、受動的から能動的にロール変更を実行しません。エンドポイントが完全に（2.2節）に指定されている場合、TCPのように、DCCP-聞くパケットが唯一DCCP-サーバーによって送信されます。
Repetition is a necessary requirement to increase robustness and the chance of successful connection establishment when a DCCP-Listen packet is lost due to congestion, link loss, or some other reason.
繰り返しは堅牢性とDCCP-聞くパケットが輻輳、リンク損失、またはその他の理由のために失われ成功した接続の確立の機会を増やすために必要な要件です。
The decision to recommend a maximum number of 3 timeouts (2 repeated copies of the original DCCP-Listen packet) results from the following consideration: the repeated copies need to be spaced sufficiently far apart in time to avoid suffering from correlated loss. The interval of 200ms was chosen to accommodate a wide range of wireless and wired network paths.
繰り返しコピーは、相関損失に苦しんで避けるための時間に十分に遠くに離間する必要があります：3つのタイムアウト（オリジナルのDCCP-聞くパケットの2つのを繰り返しコピー）以下の考察から、結果の最大数を推奨することを決定。 200msの間隔は、無線および有線ネットワークパスの広い範囲に適応するように選択しました。
Another constraint is given by the retransmission interval for the DCCP-Request ([RFC4340], Section 8.1.1). To establish state, intermediate systems need to receive a (retransmitted) DCCP-Listen packet before the DCCP-Request times out (1 second). With three timeouts, each spaced 200 milliseconds apart, the overall time is still below one second. The sum of 600 milliseconds is sufficiently large to provide for longer one-way delays, as is the case, e.g., on some wireless links.
別の制約は、DCCPリクエスト（[RFC4340]、セクション8.1.1）の再送間隔によって与えられます。状態を確立するために、中間システムはDCCP - 要求がタイムアウト（1秒）の前に（再送信）DCCP-聞くパケットを受信する必要があります。 3つのタイムアウト、それぞれ離れ200ミリ秒の間隔を置いて配置して、全体的な時間は1秒未満に依然としてあります。いくつかの無線リンク上で、例えば、そうであるように600ミリ秒の合計は、長い一方向遅延を提供するのに十分な大きさです。
The rationale behind transitioning to the LISTEN1 state after two repetitions is that other problems, independent of establishing middlebox state, may occur (such as delay or loss of the initial DCCP-Request). Any late or retransmitted DCCP-Request packets will then still reach the server, allowing connection establishment to successfully complete.
2回の繰り返しの後LISTEN1状態に遷移の理論的根拠は、ミドル状態を確立するための独立した他の問題は、（例えば、初期のDCCPリクエストの遅延または損失として）発生する可能性があることです。どれ後半または再送さDCCP-Requestパケットは、まだ接続の確立には、正常に完了できるように、サーバーに到達します。
General security considerations for DCCP are described in [RFC4340]. Security considerations for Service Codes are further described in [RFC5595].
DCCPのための一般的なセキュリティ上の考慮事項は、[RFC4340]で説明されています。サービスコードのセキュリティ上の考慮事項は、さらに、[RFC5595]で説明されています。
The method specified in this document generates a DCCP-Listen packet addressed to a specific DCCP client. This exposes the state of a DCCP server that is in a passive listening state (i.e., waiting to accept a connection from a known client).
この文書で指定されたメソッドは、DCCP-聞くパケットが特定のDCCPクライアント宛生成します。これは、受動的なリスニング状態にあるDCCPサーバの状態を公開（すなわち、既知のクライアントからの接続を受け入れるのを待っています）。
The exposed information is not encrypted and therefore could be seen on the network path to the DCCP client. An attacker on this return path could observe a DCCP-Listen packet and then exploit this by spoofing a packet (e.g., DCCP-Request or DCCP-Reset) with the IP addresses, DCCP ports, and Service Code that correspond to the values to be used for the connection. As in other on-path attacks, this could be used to inject data into a connection or to deny a connection request. A similar on-path attack is also possible for any DCCP connection, once the session is initiated by the client ([RFC4340], Section 18).
公開情報は暗号化されていないため、DCCPクライアントへのネットワークパス上で見ることができました。このリターンパス上の攻撃者が観察することができたDCCP-聞くパケットをして、パケットを偽装することで、これを利用する（例えば、DCCP-要求またはDCCP-リセット）する値に対応するIPアドレス、DCCPポート、およびサービスコード付き接続に使用されます。他のオンパス攻撃のように、これは接続にデータを注入するか、接続要求を拒否するために使用することができます。セッションは、クライアント（[RFC4340]、セクション18）によって開始されると同様のオン・パス攻撃は、任意のDCCP接続も可能です。
The DCCP-Listen packet is only sent in response to explicit, prior out-of-band signaling from a DCCP client to the DCCP server (e.g., SDP [RFC4566] information communicated via the Session Initiation Protocol [RFC3261]) and will normally directly precede a DCCP-Request sent by the client (which carries the same information).
パケットのみに応答して送信されたDCCPは、聞く、明示的に、従来は、アウトオブバンドDCCPサーバにDCCPクライアントからのシグナリング（例えば、SDP [RFC4566]セッション開始プロトコル[RFC3261]を介して通信される情報）とは、通常、直接意志（同一の情報を運ぶ）クライアントによって送られたDCCP-Requestを先行。
This update does not significantly increase the complexity or vulnerability of a DCCP implementation that conforms to [RFC4340]. A DCCP server SHOULD therefore, by default, permit generation of DCCP-Listen packets. A server that wishes to prevent disclosing this information MAY refrain from generating DCCP-Listen packets without impacting subsequent DCCP state transitions, but possibly inhibiting middlebox traversal.
この更新は、大幅に[RFC4340]に準拠DCCP実装の複雑さや脆弱性を増加させません。 DCCPサーバはそのため、デフォルトでは、DCCP-聞くパケットの生成を可能にすべきです。この情報を開示防ぐために希望するサーバーは、後続のDCCPの状態遷移に影響を与えることなく、DCCP-聞くパケットを生成するが、おそらくミドルトラバーサルを阻害することを控えることができます。
The DCCP base specification in RFC 4340 defines an Init Cookie option, which lets a DCCP server avoid having to hold any state until the three-way, connection-setup handshake has completed. This specification enables an out-of-band mechanism that forces the server to hold state for a connection that has not yet been established. This is a change in the security profile of DCCP, although the impact is expected to be minimal and depends on the security features of the out-of-band mechanism (SIP SDP is one such mechanism that provides sufficient security features).
RFC 4340でDCCPの基本仕様は、3ウェイ、接続設定ハンドシェイクが完了するまで、どのような状態を保持する必要がDCCPサーバーの回避をすることができますのInit Cookieのオプションを定義します。この仕様はまだ確立されていない接続の状態を保持するために、サーバーを強制的にアウトオブバンドメカニズムを可能にします。これは、衝撃が最小限であると予想されるが、DCCPのセキュリティプロファイルの変化であるとアウトオブバンド機構（SIP SDPは、十分なセキュリティ機能を提供するそのようなメカニズムである）のセキュリティ機能に依存します。
The method creates a new way for a client to set up a DCCP connection to a server using out-of-band data, transported over a signaling connection. If the signaling connection is not encrypted, an eavesdropper could see the client IP address and the port for the to-be-established DCCP connection, and generate a DCCP-Listen packet towards the client using its own server IP address and port. However, a client will only respond to a received DCCP-Listen packet if the server IP address and port match an existing DCCP connection that is in the REQUEST state (Section 2.3.2). The method therefore cannot be used to redirect the connection to a different server IP address.
この方法は、シグナリング接続を介して伝送帯域外のデータを使用して、サーバーへのDCCP接続を設定するには、クライアントのための新しい方法を作成します。シグナリング接続が暗号化されていない場合、盗聴者は、TO-確立さDCCP接続のためにクライアントのIPアドレスとポートを参照し、自身のサーバーのIPアドレスとポートを使用してクライアントに向けたDCCP-聞くパケットを生成することができます。サーバーのIPアドレスとポートが要求状態（2.3.2）にある既存のDCCP接続に一致する場合は、クライアントは受信DCCP-聞くパケットに応答します。この方法は、したがって、異なるサーバのIPアドレスへの接続をリダイレクトするために使用することができません。
The IANA registered a new packet type, "DCCP-Listen", in the IANA DCCP Packet Types Registry. The decimal value 10 has been assigned to this type. This registry entry references this document.
IANAはIANA DCCPパケットタイプレジストリに、新しいパケットタイプ、「DCCPは-聞く」を登録しました。進値10は、このタイプに割り当てられています。このレジストリエントリは、この文書を参照します。
This update was originally co-authored by Dr. Gerrit Renker, University of Aberdeen, and the present author acknowledges his insight in design of the protocol mechanism and in careful review of the early revisions of the document text. Dan Wing assisted on issues relating to the use of NAT and NAPT.
このアップデートでは、もともと博士ゲリットRenker、アバディーンの大学が共同執筆した、と筆者はプロトコルメカニズムの設計において、ドキュメントのテキストの早期改正を慎重に検討中の彼の洞察力を認めています。ダン・ウィングはNATとNAPTの使用に関する問題について支援しました。
[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月。
[RFC5595] Fairhurst, G., "The DCCP Service Code", RFC 5595, September 2009.
[RFC5595] Fairhurst、G.、 "DCCPサービスコード"、RFC 5595、2009年9月。
[Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem", Carnegie Mellon University/ISRI Technical Report CMU-ISRI-05-104, January 2005.
[Epp05] Eppinger、J-L、 "P2PアプリのためのTCP接続：NAT問題を解決するためのソフトウェアのアプローチ"。、カーネギーメロン大学/ ISRIテクニカルレポートCMU-ISRI-05から104、2005年1月。
[FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer Communication Across Network Address Translators", Proceedings of USENIX-05, pages 179-192, 2005.
[FSK05]フォード、B.、Srisuresh、P.、およびD.ケーゲルは、 "ネットワークを介するピア・ツー・ピア通信は、翻訳者住所"、USENIX-05の議事録、ページ179-192、2005。
[GF05] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC-05), pages 199- 211, 2005.
【GF05]グハ、S.及びP.フランシス、「特性とのNATやファイアウォールを介してTCPトラバーサルの測定」、インターネット計測会議（IMC-05）の議事録、ページ199- 211、2005。
[GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based approach to UDP and TCP connectivity", Proceedings of SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004.
[GTF04]グハ、S.、武田、Y.、およびP.フランシス、 "NUTSS：UDPとTCPの接続にSIPベースのアプローチ"、SIGCOMM-04ワークショップ、ポートランド、OR、ページ43-48、2004年の議事。
[H.323] ITU-T, "Packet-based Multimedia Communications Systems", Recommendation H.323, July 2003.
[H.323] ITU-T、 "パケットベースのマルチメディア通信システム"、勧告H.323、2003年7月。
[ICE] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2008.
[ICE]ローゼンバーグ、J.、進歩、2008年7月に仕事 "インタラクティブ接続確立（ICE）とのTCP候補"。
[NAT-APP] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[NAT-APP]フォード、B.は、進歩、2007年3月に、仕事を「ネットワークを介してトラバーサルのためのアプリケーション設計のガイドラインは、翻訳者アドレス」。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[RFC3235] Senie、D.、 "ネットワークアドレス変換（NAT）フレンドリアプリケーションの設計ガイドライン"、RFC 3235、2002年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[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月。
[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月。
[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", BCP 150, RFC 5597, September 2009.
[RFC5597]デニス・Courmont、R.、 "ネットワークアドレス変換（NAT）データグラム輻輳制御プロトコルのための行動の要件"、BCP 150、RFC 5597、2009年9月。
[STUN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, June 2009.
[STUN]ローゼンバーグ、J.、マーイ、R.、およびP.マシューズ、 "トラバーサルNAT（TURN）の周りにリレーを使用する：NAT（STUN）のセッショントラバーサルユーティリティにリレー拡張機能"、進歩、2009年6月に作業を。
Appendix A. Discussion of Existing NAT Traversal Techniques
既存のNATトラバーサル技術の付録A.ディスカッション
This appendix provides a brief review of existing techniques to establish connectivity across NAT devices, with the aim of providing background information. It first considers TCP NAT traversal based on simultaneous-open, and then discusses a second technique based on role reversal. Further information can be found in [GTF04] and [GF05].
この付録では、背景情報を提供することを目的として、NATデバイス間の接続性を確立するために、既存の技術の簡単なレビューを提供します。これは、最初に同時オープンに基づいてTCP NATトラバーサルを考慮して、役割の反転に基づいて第2の手法について説明します。さらなる情報は、[GTF04]と[GF05]に見出すことができます。
A central idea shared by these techniques is to make peer-to-peer sessions look like "outbound" sessions on each NAT device. Often a rendezvous server, located in the public address realm, is used to enable clients to discover their NAT topology and the addresses of peers.
これらの技術で共有中心的な考えは、ピア・ツー・ピアセッションは、各NATデバイス上の「アウトバウンド」のセッションのように見えるようにすることです。多くの場合、パブリックアドレスレルムにあるランデブーサーバは、そのNATトポロジーとピアのアドレスを発見するために、クライアントを有効にするために使用されます。
The term 'hole punching' was coined in [FSK05] and refers to creating soft state in a traditional NAT device by initiating an outbound connection. A well-behaved NAT can subsequently exploit this to allow a reverse connection back to the host in the private address realm.
用語「ホールパンチングは」[FSK05]に造語とアウトバウンド接続を開始することによって、伝統的なNAT装置にソフト状態を作成することを意味しました。行儀NATはその後、バックプライベートアドレスレルムのホストへの逆接続を許可するように、これを利用することができます。
UDP and TCP hole punching use nearly the same technique [RFC4787]. The adaptation of the basic UDP hole punching principle to TCP NAT traversal [RFC5382] was introduced in Section 4 of [FSK05] and relies on the simultaneous-open feature of TCP [RFC0793]. A further difference between UDP and TCP lies in the way the clients perform connectivity checks after obtaining suitable address pairs for connection establishment. Whereas in UDP a single socket is sufficient, TCP clients require several sockets for the same address and port tuple:
UDPとTCPホールパンチング使用ほぼ同じ手法[RFC4787]。 TCP NATトラバーサル[RFC5382]への基本的なUDPホールパンチング原則の適応は[FSK05]のセクション4で導入され、TCP [RFC0793]の同時オープン機能に依存していました。 UDPとTCPの間に更なる違いは、クライアントが接続の確立のために、適切なアドレスのペアを取得した後、接続性チェックを行う方法です。 UDPでシングルソケットで十分であるのに対し、TCPクライアントが同じアドレスとポートのタプルのためのいくつかのソケットが必要です。
o a passive socket to listen for connectivity tests from peers, and
ピアからの接続テストをリッスンするパッシブソケットO、および
o multiple active connections from the same address to test reachability of other peers.
O同じアドレスから複数のアクティブ接続が他のピアの到達可能性をテストします。
The SYN sent out by client A to its peer B creates soft state in A's NAT. At the same time, B tries to connect to A:
ピアBにクライアントAから送信されたSYNはAのNATにおけるソフトステートを作成します。同時に、BはAに接続しようとします：
o if the SYN from B has left B's NAT before the arrival of A's SYN, both endpoints perform simultaneous-open (4-way handshake of SYN/ SYNACK);
BからSYNがAのSYNの到着前にBのNATを離れた場合にO、両方のエンドポイントは、同時オープン（SYN / SYNACKの4ウェイハンドシェイク）を行います。
o otherwise, A's SYN may not enter B's NAT, which leads to B performing a normal open (SYN_SENT => ESTABLISHED) and A performing a simultaneous-open (SYN_SENT => SYN_RCVD => ESTABLISHED).
Oそうでなければ、AのSYNは、ノーマルオープン（SYN_SENT => ESTABLISHED）と同時オープン（SYN_SENT => SYN_RCVD =>がESTABLISHED）実行を行うBにつながるBのNATを入力しなくてもよいです。
In the latter case, it is necessary that the NAT does not interfere with a RST segment (REQ-4 in [RFC5382]). The simultaneous-open solution is convenient due to its simplicity, and is thus a preferred mode of operation in the TCP extension for Interactive Connectivity Establishment (ICE) ([ICE], Section 2).
後者の場合には、NATは、RSTセグメント（REQ-4 [RFC5382]で）を妨害しないことが必要です。同時オープンソリューションは、その単純に便利であるため、インタラクティブ接続確立（ICE）（[ICE]、セクション2）のためのTCP拡張における好ましい動作モードです。
A.1. NAT Traversal Based on a Simultaneous-Request
A.1。同時リクエストに基づいて、NATトラバーサル
Among the various TCP NAT traversal approaches, the one using a TCP simultaneous-open suggests itself as a candidate for DCCP due to its simplicity ([GF05], [NAT-APP]).
様々なTCPのNATトラバーサルのアプローチのうち、同時オープンTCPを用いたものは、その単純さ（[GF05]、[NAT-APP]）にDCCPの候補としての地位を示唆しています。
A characteristic of TCP simultaneous-open is that this erases the clear distinction between client and server: both sides enter through active (SYN_SENT) as well as passive (SYN_RCVD) states. This characteristic conflicts with the DCCP design decision to provide a clear separation between client and server functions ([RFC4340], Section 4.6).
同時オープンTCPの特性は、これは、クライアントとサーバとの間の明確な区別を消去することである：両側がアクティブ（SYN_SENT）を介して入力し、並びに受動（SYN_RCVD）状態。クライアントとサーバー機能（[RFC4340]、セクション4.6）との間に明確な分離を提供するために、DCCPの設計上の決定を持つこの特性競合します。
In DCCP, several mechanisms implicitly rely on clearly defined client/server roles:
DCCPでは、いくつかのメカニズムは、暗黙的に明確に定義されたクライアント/サーバーの役割に依存しています：
o Feature Negotiation: with few exceptions, almost all of DCCP's negotiable features use the "server-priority" reconciliation rule ([RFC4340], Section 6.3.1), whereby a peer exchanges its preference lists of feature values, and the server decides the outcome.
O機能のネゴシエーション：特徴値のその優先リストピアの交換、およびサーバが決定したことにより、いくつかの例外を除いて、ほぼすべてのDCCPの交渉機能の「サーバー優先」和解のルール（[RFC4340]、セクション6.3.1）を使用します結果。
o Closing States: only a server may generate DCCP-CloseReq packets (asking the peer to hold timewait state), while a client is only permitted to send DCCP-Close or DCCP-Reset packets to terminate a connection ([RFC4340], Section 8.3).
Oクローズ状態：クライアントのみ接続（[RFC4340]、セクション8.3を終了するDCCPクローズまたはDCCP - リセットパケットを送信することが許可されている間のみ、サーバが、DCCP-CloseReqパケット（TIMEWAIT状態を保持するピアを求める）を生成してもよいです）。
o Service Codes [RFC5595]: a server may be associated with multiple Service Codes, while a client must be associated with exactly one ([RFC4340], Section 8.1.2).
Oサービスコード[RFC5595]：クライアントは、ちょうど1つの（[RFC4340]、セクション8.1.2）に関連付けられている必要がありながら、サーバは、複数のサービスコードに関連付けられてもよいです。
o Init Cookies: may only be used by a server and on DCCP-Response packets ([RFC4340], Section 8.1.4).
O初期クッキー：サーバのみによって、およびDCCP - 応答パケット（[RFC4340]、セクション8.1.4）上で使用することができます。
The latter two points are not obstacles per se, but would have hindered the transition from a passive to an active socket. In DCCP, a DCCP-Request is only generated by a client. The assumption that "all DCCP hosts may be clients" was dismissed, since it would require undesirable changes to the state machine and would limit application programming. As a consequence, the retro-fitting of a TCP-style simultaneous-open into DCCP to allow simultaneous exchange of DCCP-Connect packets was not recommended.
後者の二つのポイントは、それ自体の障害ではなく、受動からアクティブソケットへの移行を妨げたであろう。 DCCPでは、DCCP-Requestが、クライアントのみによって生成されます。それは、ステートマシンへの望ましくない変更を必要とし、アプリケーション・プログラミングを制限するため、「すべてのDCCPのホストがクライアントかもしれ」という仮定が、却下されました。その結果、DCCP-接続パケットの同時交換を可能とするDCCPに同時オープンTCPスタイルのレトロフィットは推奨されませんでした。
A.2. Role Reversal
A.2。立場逆転
Another simple TCP NAT traversal scheme uses role traversal ([Epp05], [GTF04]), where a peer first opens an active connection for the single purpose of punching a hole in the firewall, and then reverts to a listening socket, accepting connections that arrive via the new path.
別の単純なTCP NATトラバーサル方式が役割トラバーサルを使用する（[Epp05]、[GTF04]）、ピアが最初にファイアウォールに穴を打ち抜く単一の目的のためにアクティブな接続を開き、その接続を受け付け、リスニングソケットに戻り新しいパスを経由して到着しました。
This solution would have had several disadvantages if used with DCCP. First, a DCCP server would be required to change its role to temporarily become a 'client'. This would have required modification to the state machine -- in particular, the treatment of Service Codes and perhaps Init Cookies. Further, the method would have needed to follow feature negotiation, since an endpoint's choice of initial options can rely on its role (i.e., an endpoint that knows it is the server can make a priori assumptions about the preference lists of features it is negotiating with the client, thereby enforcing a particular policy). Finally, the server would have needed additional processing to ensure that the connection arriving at the listening socket matches the previously opened active connection.
DCCPで使用する場合は、このソリューションは、いくつかの欠点があっただろう。まず、DCCPサーバーが一時的に「クライアント」になるための役割を変更するために必要とされるであろう。具体的には、サービスコードと、おそらく初期クッキーの治療 - これは、ステートマシンへの変更を必要としました。初期オプションのエンドポイントの選択は、その役割に依存することができますので、この方法は、（すなわち、それはサーバーであることを知っているエンドポイントは、それはと交渉している機能の優先リストに関する先験的仮定を行うことができ、機能ネゴシエーションを追跡するのに必要でしょうこれにより、特定のポリシーを適用するクライアント、）。最後に、サーバーは、リスニングソケットに到着接続が以前に開かれたアクティブな接続と一致することを確実にするために追加の処理を必要としているでしょう。
This approach was therefore not recommend for DCCP.
このアプローチは、したがって、DCCPのためにお勧めしていませんでした。
Author's Address
著者のアドレス
Godred Fairhurst University of Aberdeen School of Engineering Fraser Noble Building Aberdeen AB24 3UE Scotland
エンジニアリング・フレイザーノーブルビルアバディーンAB24 3UEスコットランドのアバディーン大学のGodred Fairhurst大学
EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk
電子メール：gorry@erg.abdn.ac.uk URI：http://www.erg.abdn.ac.uk