[要約] 要約： RFC 5596は、DCCPプロトコルのSimultaneous-Openテクニックを使用して、NATやミドルボックスのトラバーサルを容易にするためのガイドラインを提供しています。目的： このRFCの目的は、DCCPプロトコルを使用してネットワーク上での通信を改善し、NATやミドルボックスの制約を克服することです。
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.
このドキュメントは、接続指向およびデータグラムベースのトランスポートプロトコルであるDatagramうっ血コントロールプロトコル（DCCP）の更新を指定します。この更新により、DCCP-Listenパケットのサポートが追加されます。これにより、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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
Datagramの混雑制御プロトコル（DCCP）[RFC4340]は、データグラムベースで接続指向の両方です。RFC 4340によると、DCCPサーバーは、DCCPクライアントによって積極的に送信される着信接続要求を受動的に聞くことにより、接続を確立します。これらの非対称の役割は、サーバーがネットワークアドレスポート変換（NAPT）などのミドルボックスの「内部」にある場合に問題を引き起こす可能性があります。ホストベースおよびネットワークファイアウォールは、同様の問題につながるポリシーを実装することもできます。この動作は現在、多くのファイアウォールのデフォルトです。
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のコネクションのない性質を活用するため、DCCPには適していないさまざまな手法[RFC4787]を使用して、Middleboxトラバーサルをサポートできます。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ステートマシンの更新を指定して、DCCPクライアントが1つ以上のミドルボックス内にあるDCCPサーバーへの接続を確立できるネイティブサポートを提供します。これにより、「ホールパンチング」として知られる広く使用されている原理を明示的にサポートすることにより、データリレーサーバー[スタン]などの外部エイズへの依存が減少します。
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サーバーがミドルボックスによって制御された境界内に配置されている場合のシナリオで役立ちます。Voice over IP（VoIP）、ファイル共有、オンラインゲームなど、クライアント/サーバーとピアツーピアアプリケーションの両方に関連し、以前の帯域外シグナル伝達を利用する接続を支援します（例えば、ウェルを介して-Condound Rendezvous Server（[RFC3261]、[H.323]）））接続パラメーターの両方のエンドポイント（[RFC3235]、[NAT-APP]）を通知します。
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デバイスの階層が可能です）。このドキュメントでは、1つまたは複数のNAPTデバイスによって制御された境界内にあるDCCPホストが「プライベート」アドレスを持っていると制御され、グローバルアドレスの領域にあるDCCPホストが「パブリック」アドレスを持っていると考えています。
DCCP NAT traversal is considered for the following scenarios:
DCCP NATトラバーサルは、次のシナリオで考慮されます。
1. Private client connects to public server.
1. プライベートクライアントはパブリックサーバーに接続します。
2. Public client connects to private server.
2. パブリッククライアントはプライベートサーバーに接続します。
3. Private client connects to private server.
3. プライベートクライアントはプライベートサーバーに接続します。
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]の定義的な特徴は、プライベートホストが外部ホストに接続できることですが、その逆ではありません。したがって、[RFC4340]で定義されているプロトコルを使用して、ケース（1）が可能です。事前に構成された静的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]に適合するDCCP実装と[RFC5597]に準拠するNATデバイスには、ケース（2）および（3）に対してNATトラバーサルを実行するためにDCCPリレーサーバーが必要です。
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]).
このドキュメントでは、DCCPリレーサーバーを使用せずにケース（2）および（3）をサポートする方法について説明します。このメソッドはRFC 4340を更新し、DCCPサーバーにIPアドレスと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接続は2つのホスト間で実行されます。これは、DCCP AとDCCP Bと名付けられることがよくあります。各接続は、クライアントと呼ばれるホストの1つによって積極的に開始されます。もう1つは、最初はパッシブホストがサーバーと呼ばれます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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>.
「セッション」という用語は、（[RFC2663]、セクション2.3）で定義されているように使用されます。DCCPセッションは、<ソースIPアドレス、ソースポート、ターゲットIPアドレス、ターゲットポート>の4タプルによって一意に識別されます。
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-Listenが追加されています。その形式を以下に示します。
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-Listenパケットの形式
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 ソースポートフィールドは、パケット内の宛先IPアドレスとして表示されるIPアドレスからの接続をDCCPサーバーがリスニングしているポートを示します。
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).
o xの値は1に設定する必要があります。接続が確立される前にDCCP-Listenパケットが送信されます。したがって、短いシーケンス番号の使用を交渉する方法はありません（[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:
o DCCP-Listenパケットのシーケンス番号フィールドの値は、通常のDCCPメッセージで使用されるDCCPシーケンス番号とは関係ありません（DCCPシーケンス番号の使用の説明については、セクション3を参照）。したがって、DCCP-Listenパケットの場合：
* 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.
* ミドルボックスは、DCCP-Listenパケットのシーケンス番号を解釈してはなりません。
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]および[RFC5595]のセクション8.1.2）。この値は、同じソースIPアドレスによって識別された接続とDCCP-Listenパケットのソースポートと同じソースポートに実際に提供されているサービスコードに対応する必要があります。サーバーは複数のサービスコードを使用する可能性があるため、セッション説明プロトコルを使用して説明されているDCCP-Listenパケットを送信する前に、サービスコードフィールドの特定の値をクライアントからサーバーまで通知する必要があります（クライアントからサーバーへ）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-Listenパケットを使用したヘッダーオプション（[RFC4340]、セクション5.8）の使用は既知の使用はありません。クライアントは、受信したDCCP-Listenパケットのすべてのオプションを無視する必要があります。したがって、DCCP-Listenパケットを使用して機能値を交渉することはできません。
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-Listenパケットを使用したペイロードデータの使用は既知のものはありません。DCCP-Listenパケットは実際の接続が確立される前に発行されるため、エンドポイントはDCCP-Listenパケットで発生したペイロードデータを無視する必要があります。
o The following protocol fields are required to have specific values:
o 次のプロトコルフィールドには、特定の値が必要です。
* 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-Listenパケットを示すために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を更新しません。つまり、サーバーは図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リクエストに応答するサーバーの場合、risten1状態に移行し、すぐに応答状態に移行しても、追加のDCCP-Requestパケットの受信は必要ありません。
Figure 2: Updated State Transition Diagram for DCCP-Listen
図2：DCCP-Listenの更新された状態遷移図
This diagram introduces two additional DCCP server states in addition to those listed in Section 4.3 of [RFC4340]:
この図では、[RFC4340]のセクション4.3にリストされているものに加えて、2つの追加の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-Listenパケットを生成しているリスニング状態の完全に指定されたサーバーソケットを表します。
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.
聴取1 listen1状態は特定のDCCP接続に関連付けられており、クライアントに向かってさらにDCCP-Listenパケットを生成しないパッシブリスニング状態の完全に指定されたサーバーソケットを表します。
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-Listenパケットを送信することによって実行されます。以下の図は、招待された状態でのパケット処理を説明する擬似コードを提供します。この処理ステップは、[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を受信した場合、聴取1状態に移行し、すぐに応答状態に移行します。
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.
サーバーは、招待された状態でDCCP-Listenパケットを繰り返し、最大2つの繰り返しとともに200ミリ秒間隔で繰り返します（セクション3では、この選択の選択肢間隔について説明します）。サーバーが3番目のDCCP-Listenパケットの送信後、さらに200ミリ秒の期間後も招待された状態にある場合、risten1状態に進むはずです。
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-Listenパケットに応じて受信したICMPエラーメッセージを、状態の移行を引き起こさない「ソフトエラー」として扱う必要があります。DCCP-Listenパケットを送信した結果としてのICMPエラーメッセージの受信は、必ずしも次の接続要求の障害を示すわけではないため、サーバー状態の変更につながるべきではありません。ソフトエラーに対するこの反応は、多くのネットワーク障害で、エンドポイントを混乱させることなくネットワークを動的に再構築できるインターネットの貴重な機能を活用します。
Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A DCCP server in the LISTEN, INVITED, or LISTEN1 states MAY generate a 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-Listenパケットを無視する必要があります。リスニング、招待、または聴取のDCCPサーバーは、受信したDCCP-Listenパケットに応じて、DCCP-Resetパケット（コード7、「接続拒否」）を生成する場合があります。このDCCP-Resetパケットは、同じポートの接続を同時に待っている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：Invited and Listen1 STATESのための更新されたDCCP PSEUDOCODE
This document updates Section 8.1.1 of [RFC4340] by adding the following rule for the reception of DCCP-Listen packets by clients:
このドキュメントは、クライアントによるDCCP-Listenパケットの受信のために次のルールを追加することにより、[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-Listenパケット（セクション2.2.1）で遭遇するヘッダーオプションまたはペイロードデータを無視するために必要であるため、クライアントに意味のあるコミュニケーションを提供しません。次のセクションで定義されているオプションの手順を実装しない限り、どの州のクライアントも受信したDCCP-Listenパケットを静かに廃棄する必要があります。
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のドロップ後にタイムアウトを待つ必要がないようにします。この操作では、クライアントがリクエスト状態で受信したときにDCCP-Listenパケットの受信に応答する必要があります。DCCP-Listenパケットは、他のすべての状態で静かに廃棄する必要があります。
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-Listenパケットを受信した後、すぐにDCCP-Requestの再送信を実行する場合があります。再送信は、リクエスト状態[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).
200msを超えるパス遅延により、DCCP応答が受信される前にクライアントに到着する複数のDCCP-Listenパケットが到着することに注意してください。したがって、クライアントは、各DCCP接続に対してこのような再送信を1つだけ実行する必要があります。これには、ローカル状態を維持する必要があります（たとえば、接続ごとに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要求を受信するサーバー（つまり、1つの不要なパケットを送信するサーバー）を受信する可能性があることに注意する必要があります。これにより、クライアントが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-Listenパケットは特別な処理を必要とせず、したがって、ルーターとミドルボックスの両方によって、インターネットパス全体にエンドツーエンドを転送する必要があります。
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].
ミドルボックスは、接続情報（アドレス、ポート、サービスコード）を利用して、ローカル転送状態を確立する場合があります。DCCP-Listenパケットには、DCCPサービスコード値[RFC5595]を含むソースおよび宛先アドレス（IPヘッダーに含まれている）と組み合わせてDCCPセッションを一意に識別するために必要な情報が搭載されています。NATデバイスによるDCCP-Listenパケットの処理は、[RFC5597]で指定されています。
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 Bの前に配置されます。NAとNBの両方がDCCPパケットがリンクを発信するためにデバイスをトラバースすることを許可するポリシーを使用しますが、以前のパケットが同じ接続のために送信されたときに、着信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-Listenメッセージを送信することにより、リスニング状態を積極的に示します。これにより、NBに穴を開けるという要件が満たされます（また、外部アドレスとポートへのバインディングを作成します）。このメッセージは、まだ穴がないため、NAによってドロップされます。DCCP Aは、リクエスト状態を入力し、DCCP-Requestを送信することにより、接続を開始します。（NAがNATデバイスである場合、これにより、ピンホールを外部アドレスとポートにマッピングするバインディングが生じると想定されています。）DCCP-Requestは、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リケストを受信しない場合を考慮します（多くの場合、このインターバル内でリクエストが受信されます）。
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-Listenパケットの繰り返しは、タイマーを使用して実装できます。各DCCP-Listenパケットを送信すると、タイマーは200msの間隔で再起動されます。サーバーが招待された状態を離れると、キャンセルされます。タイマーが1番目と2番目の送信の後に期限切れになると、別のDCCP-Listenパケットの送信がトリガーされます。3番目のDCCP-Listenパケットを送信した後に期限切れになった場合、サーバーは招待された状態を離れてListen1状態に入ります（DCCP-Requestを受動的に待機します）。
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-Listenパケットの繰り返し
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.
次の図は、トリガーされた再送信を示しています。この図では、最初のDCCP-Listenはネットワークで失われていると想定されています（たとえば、NBでピンホールを開けません）。後のDCCP-Requestも受信されていません（おそらく最初の損失の副作用として）。200ms後、DCCP-Listenパケットが再送信され、正しく受信されます。これにより、DCCP-Requestの再送信が引き起こされ、受信した場合、対応する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-ListenとDCCP-Requestが順番に処理されたときに交換されたパケットのシーケンスを示しています。クライアントによるDCCP-Listenパケットの受信は、DCCP-Requestの再送信をトリガーします。サーバーは最初のDCCP-Requestに応答し、応答状態に入ります。サーバーはその後、2番目の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]のみを実装する場合、[RFC4340]のセクション8.1のステップ1のために、着信DCCP-Listenパケットは無視され、同時にこのドキュメントで指定された動作にも適合します。
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-Listenパケットは、DCCP-Requestパケット（[RFC4340]、セクション5.1）と同じ形式を持っています。唯一の違いは、タイプフィールドの値です。ただし、使用法は異なります。DCCP-Listenパケットは、実際の接続セットアップの一部としてではなく、アドバイザリーメッセージとして機能します。シーケンス番号には意味がなく、ペイロードを伝えることができません。
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-Requestは、3ウェイハンドシェイクの初期パケットである明確な目的を果たします。DCCP-Listenパケットの方法での追加の使用では、DCCPプロセッサに2つの異なる処理パスを持たせる必要がありました。1つはDCCP-Requestが最初の握手の一部として解釈され、もう1つは同じパケットがの兆候として解釈された場合新しい接続を受け入れる意図。これにより、ホストのパケット処理、特にステートフルミドルボックス（計算リソースが制限されている可能性があります）が複雑になります。
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.
2番目の問題は、サーバーからDCCP-Requestを受信したクライアントが、要求状態をまだ入力していない場合、DCCPレセットパケットを生成できることです（[RFC4340]のセクション8.5のステップ7）。このドキュメントで指定された方法により、クライアントのエンドポイントはDCCP-Listenパケットを無視できます。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シンクパケットを使用してサーバーからDCCP-Requestに返信する必要があります。このタイプのメッセージに対してシーケンス番号は無視されるため、追加の複雑な処理が必要になります。リクエストが表示として使用されているときにDCCPリケストに応答しないようにクライアントに依頼するか、DCCPを無視するようにミドルボックスとサーバーに依頼することです。-syncパケットは、表示として使用されるDCCP-Requestパケットに応じて生成されました。さらに、この段階では初期シーケンス番号が交渉されていないため、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-Listenシーケンス番号フィールドは無視されていますが、[RFC4340]のセクション5.1の汎用ヘッダー形式を再利用するために、DCCP-Listenパケットヘッダーに保持されています。
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-Listenパケットの場合、この値をゼロに設定するために送信者が必要です。この値を無視するには、クライアントとミドルボックスの両方が必要です。
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-Listenパケットのシーケンス番号フィールドを無視する理由は、DCCP-Listenが交換されているときに、エンドポイントがまだ接続セットアップを入力していないことです。-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-Listenパケットの生成を許可する必要があります。DCCP-ListenパケットはNATおよび/またはファイアウォールトラバーサルの特定の問題を解決するため、パッシブソケットでのDCCP-Listenパケットの生成は、条件に結び付けられています（両方とも先験的に知られているリモートアドレスとサービスコードに結合します）。これは、「通常の」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).
TCPの世界では、アナログはデータを送信することにより、syn_sentに耳を傾けることからの移行です。「その後の送信の実行によって完全に指定されたパッシブコールをアクティブにすることができます」（[RFC0793]、セクション3.8）。TCPとは異なり、このアップデートはパッシブからアクティブへの役割の変更を実行しません。TCPと同様に、DCCP-Listenパケットは、エンドポイントが完全に指定されている場合にのみDCCPサーバーによって送信されます（セクション2.2）。
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-Listenパケットが失われた場合に、堅牢性と接続確立の成功の可能性を高めるために必要な要件です。
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-Listenパケットの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-Requestの再送信間隔（[RFC4340]、セクション8.1.1）によって与えられます。状態を確立するには、中間システムがDCCP-Requestタイムズ（1秒）の前に（再送信）DCCP-Listenパケットを受信する必要があります。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-Requestの遅延や損失など）。遅いまたは再送信された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-Listenパケットを生成します。これにより、受動的なリスニング状態にある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-Listenパケットを観察し、IPアドレス、DCCPポート、および値に対応するサービスコードを使用してパケット（DCCP-RequestまたはDCCP-Resetなど）をスプーフィングすることにより、これを悪用する可能性があります。接続に使用されます。他のパス攻撃と同様に、これを使用して、データを接続に挿入したり、接続要求を拒否したりできます。セッションがクライアントによって開始されると（[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-Listenパケットは、セッション開始プロトコル[RFC3261]を介して伝達されるDCCPクライアントからDCCPサーバー（例：SDP [RFC4566]）へのDCCPクライアント（例：SDP [RFC4566]）への明示的な以前の帯域外シグナリングに応じてのみ送信され、通常は直接的に直接的になります。クライアントから送信された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-Listenパケットの生成を許可する必要があります。この情報の開示を防ぐことを希望するサーバーは、後続のDCCP状態の遷移に影響を与えることなく、DCCP-Listenパケットの生成を控えることができますが、おそらくミドルボックストラバーサルを阻害する可能性があります。
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ベース仕様は、INIT Cookieオプションを定義します。これにより、DCCPサーバーは、3方向の接続セットアップハンドシェイクが完了するまで状態を保持する必要があります。この仕様により、サーバーがまだ確立されていない接続の状態を保持するように強制するバンド外のメカニズムを可能にします。これはDCCPのセキュリティプロファイルの変化ですが、影響は最小限であると予想され、バンド外のメカニズムのセキュリティ機能に依存します（SIP SDPは、十分なセキュリティ機能を提供するメカニズムの1つです）。
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接続を設定する新しい方法を作成します。信号接続が暗号化されていない場合、盗聴者は、確立されたDCCP接続のクライアントIPアドレスとポートを表示し、独自のサーバーIPアドレスとポートを使用してクライアントに向かってDCCP-Listenパケットを生成できます。ただし、クライアントは、サーバーIPアドレスとポートが要求状態にある既存のDCCP接続と一致する場合にのみ、受信したDCCP-Listenパケットに応答します（セクション2.3.2）。したがって、この方法を使用して、接続を別のサーバー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-Listen」を登録しました。小数値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.
この更新はもともと、アバディーン大学のゲリット・レンカー博士によって共著されており、現在の著者は、プロトコルメカニズムの設計に関する洞察と、文書テキストの初期改訂を慎重に検討していることを認めています。ダン・ウィングは、NATとNAPTの使用に関連する問題を支援しました。
[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うっ血制御プロトコル（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] Ford、B.、Srisuresh、P。、およびD. Kegel、「ネットワークアドレス翻訳者全体のピアツーピア通信」、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] Guha、S。およびP. Francis、「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] Guha、S.、Takeda、Y.、およびP. Francis、「Nutss：UDPおよびTCP接続へのSIPベースのアプローチ」、Sigcomm-04ワークショップの議事録、ポートランド、オレゴン州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] Rosenberg、J。、「Interactive Connectivity Indecivity Indecivity（ICE）を備えたTCP候補」、2008年7月の作業。
[NAT-APP] Ford, B., "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[NAT-APP] Ford、B。、「ネットワークアドレス翻訳者を介したトラバーサルのアプリケーション設計ガイドライン」、2007年3月、Work in Progress。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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. Holdrege、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、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] Denis-Courmont、R。、「Network Address Translation（NAT）Datagram輻輳制御プロトコルの行動要件」、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] Rosenberg、J.、Mahy、R。、およびP. Matthews、「NATの周りのリレーを使用したトラバーサル（ターン）：NAT（STUN）のセッショントラバーサルユーティリティへのリレー拡張機能」、2009年6月の作業。
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:
クライアントAからピアBに送信された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);
o bからのsynがAのsynの到着前にBのNATを去った場合、両方のエンドポイントは同時オープン（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はBのNATに入ることはできません。これにより、Bは通常のオープン（Syn_Sent =>確立）を実行し、Aを同時にオープン（Syn_Sent => syn_rcvd =>確立）を実行します。
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セグメントを妨害しないことが必要です（[RFC5382]のREQ-4）。同時に開かれたソリューションは、そのシンプルさのために便利であるため、インタラクティブ接続の確立（ICE）のTCP拡張で好ましい動作モードです（[ICE]、セクション2）。
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同時オープンを使用するものは、その単純さのためにDCCPの候補としての地位を示唆しています（[GF05]、[NAT-APP]）。
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同時オープンの特徴は、これによりクライアントとサーバーの明確な区別が消去されることです。この特徴は、クライアント機能とサーバー機能の明確な分離を提供するDCCP設計決定と矛盾しています（[RFC4340]、セクション4.6）。
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 閉じる状態：サーバーのみがDCCP-Closereqパケットを生成することができます（ピアにタイムウェイトステートを保持するように求めます）。クライアントは、接続を終了するためにDCCPクロースまたはDCCP-レセットパケットを送信することのみを許可されます（[RFC4340]、セクション8.3）。
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 Cookieを開始：サーバーと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.
後者の2つのポイントは障害ではありませんが、パッシブからアクティブソケットへの移行を妨げていました。DCCPでは、DCCP-Requestはクライアントによってのみ生成されます。「すべてのDCCPホストがクライアントである可能性がある」という仮定は却下されました。これは、状態マシンの望ましくない変更が必要であり、アプリケーションプログラミングを制限するためです。結果として、DCCPに合わせてTCPスタイルの同時に整備されたレトロフィッティングは、DCCP接続パケットの同時交換を可能にすることは推奨されませんでした。
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サーバーが一時的に「クライアント」になるためにその役割を変更する必要があります。これには、状態マシン、特にサービスコードの処理とおそらくCookieを開始するための変更が必要になります。さらに、エンドポイントの初期オプションの選択がその役割に依存できるため、この方法は機能交渉に従う必要がありました（つまり、サーバーが交渉している機能の優先リストについて先験的に仮定できることを知っているエンドポイントはクライアントは、特定のポリシーを実施します）。最後に、サーバーは、リスニングソケットに到達する接続が以前に開かれたアクティブ接続と一致するようにするために追加の処理が必要でした。
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 3Uスコットランド
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk