Network Working Group S. Guha, Ed.
Request for Comments: 5382 Cornell U.
BCP: 142 K. Biswas
Category: Best Current Practice Cisco Systems
B. Ford
MPI-SWS
S. Sivakumar
Cisco Systems
P. Srisuresh
Kazeon Systems
October 2008
NAT Behavioral Requirements for TCP
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
抽象
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
この文書では、このようなピア・ツー・ピア・アプリケーションやオンラインゲームなどの多くのアプリケーションは、一貫して動作することができるようになるTCPを扱うNATのための要件のセットを定義します。要件のこのセットを満たすのNATの開発は大幅にこれらのアプリケーションが正常に機能する可能性を増加します。
Table of Contents
目次
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 5
4.2. Internally Initiated Connections . . . . . . . . . . . . . 5
4.3. Externally Initiated Connections . . . . . . . . . . . . . 7
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10
6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12
7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12
7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12
7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13
7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informational References . . . . . . . . . . . . . . . . . 18
This document is adjunct to [BEHAVE-UDP], which defines many terms relating to NATs, lays out general requirements for all NATs, and sets requirements for NATs that handle IP and unicast UDP traffic. The purpose of this document is to set requirements for NATs that handle TCP traffic.
この文書では、NATのに関連する多くの用語を定義し、すべてのNATのための一般的な要件をレイアウト、およびIPユニキャストUDPトラフィックを処理するNATのための要件を設定し、[BEHAVE-UDP]、の補助です。このドキュメントの目的は、TCPトラフィックを処理するNATの要件を設定することです。
The requirements of this specification apply to traditional NATs as described in [RFC2663].
[RFC2663]に記載されているように、この仕様の要件は、従来のNATに適用されます。
This document only covers the TCP aspects of NAT traversal. Middlebox behavior that is not necessary for network address translation of TCP is out of scope. Packet inspection above the TCP layer and firewalls are out of scope except for Application Level Gateway (ALG) behavior that may interfere with NAT traversal. Application and OS aspects of TCP NAT traversal are out of scope. Signaling-based approaches to NAT traversal, such as Middlebox Communication (MIDCOM) and Universal Plug and Play (UPnP), that directly control the NAT are out of scope. Finally, TCP connections intended for the NAT (e.g., an HTTP or Secure Shell Protocol (SSH) management interface) and TCP connections initiated by the NAT (e.g., reliable syslog client) are out of scope.
この文書では、唯一のNATトラバーサルのTCPの側面をカバーしています。 TCPのネットワークアドレス変換のために必要ではないミドルの動作は範囲外です。 TCP層およびファイアウォール上記パケット検査は、NATトラバーサルを妨害する可能性アプリケーションレベルゲートウェイ（ALG）の動作を除い範囲外です。 TCP NATトラバーサルのアプリケーションとOSの側面は範囲外です。シグナリングベースようなミドルコミュニケーション（MIDCOM）とユニバーサルプラグアンドプレイ（UPnP）などのNATトラバーサルのアプローチは、それが直接NATを制御する範囲外です。最後に、TCP接続がNAT（例えば、HTTPまたはシェルプロトコル（SSH）管理インターフェイスをセキュア）とNAT（例えば、信頼性のsyslogクライアント）によって開始されたTCP接続範囲外であるためのもの。
Network Address Translators (NATs) hinder connectivity in applications where sessions may be initiated to internal hosts. Readers may refer to [RFC3022] for detailed information on traditional NATs. [BEHAVE-UDP] lays out the terminology and requirements for NATs in the context of IP and UDP. This document supplements these by setting requirements for NATs that handle TCP traffic. All definitions and requirements in [BEHAVE-UDP] are inherited here.
ネットワークアドレス変換器（NAT）は、セッションが内部ホストに開始することができるアプリケーションで接続を妨げます。読者は、従来のNATの詳細については[RFC3022]を参照することができます。 [BEHAVE-UDP]はIPやUDPの文脈における用語とNATのための要件をレイアウトします。このドキュメントでは、TCPトラフィックを処理するNATの要件を設定することにより、これらを補足します。 [BEHAVE-UDP]のすべての定義や要件は、ここで継承されます。
[RFC4614] chronicles the evolution of TCP from the original definition [RFC0793] to present-day implementations. While much has changed in TCP with regards to congestion control and flow control, security, and support for high-bandwidth networks, the process of initiating a connection (i.e., the 3-way handshake or simultaneous-open) has changed little. It is the process of connection initiation that NATs affect the most. Experimental approaches such as T/TCP [RFC1644] have proposed alternate connection initiation approaches, but have been found to be complex and susceptible to denial-of-service attacks. Modern operating systems and NATs consequently primarily support the 3-way handshake and simultaneous-open modes of connection initiation as described in [RFC0793].
[RFC4614]は実装日に存在する元の定義からTCPの進化[RFC0793]を追っ。はるかには、輻輳制御に関してTCPに変更し、高帯域幅ネットワーク用の制御、セキュリティ、およびサポートを流れてきたが、接続を開始する処理（すなわち、3ウェイハンドシェイクまたは同時オープン）が少し変化しています。それは、NATのが最も影響を与える接続開始のプロセスです。そのようなT / TCP [RFC1644]などの実験的アプローチは、代替の接続開始のアプローチを提案しているが、複雑で、サービス拒否攻撃を受けやすいことが判明しています。 [RFC0793]に記載されているように現代のオペレーティング・システムとのNATは、結果として主に3ウェイハンドシェイクと接続開始の同時オープンモードをサポートします。
Recently, many techniques have been devised to make peer-to-peer TCP applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow peer-to-peer applications to establish TCP through NATs. These approaches require only endpoint applications to be modified and work with standards compliant OS stacks. The approaches, however, depend on specific NAT behavior that is usually, but not always, supported by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently, a complete TCP NAT traversal solution is sometimes forced to rely on public TCP relays to traverse NATs that do not cooperate. This document defines requirements that ensure that TCP NAT traversal approaches are not forced to use data relays.
最近、多くの技術は、ピア・ツー・ピアのTCPアプリケーションがNATを越えて動作させるために考案されています。 [STUNT]は、[NATBLASTER]、および[P2PNAT]片側自アドレス固定（UNSAF）ピア・ツー・ピア・アプリケーションがNATを介してTCPを確立することを可能にするメカニズムを記述する。これらのアプローチは、エンドポイントのみのアプリケーションが変更され、標準に準拠OSスタックで動作させる必要があります。アプローチ、しかし、通常は特定のNAT動作に依存し、常にではないが、NATのでサポートされている（[TCPTRAV]と[P2PNAT]詳細については、を参照）。その結果、完全なTCP NATトラバーサルソリューションは、時には協力しないのNATを横断する公共のTCPリレーに頼ることを余儀なくされます。このドキュメントでは、TCP NATトラバーサルのアプローチは、データリレーを使用するように強制されていないことを確認する要件を定義します。
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]に記載されているように解釈されます。
"NAT" in this specification includes both "Basic NAT" and "Network Address/Port Translator (NAPT)" [RFC2663]. The term "NAT Session" is adapted from [NAT-MIB] and is defined as follows.
本明細書における「NAT」とは、「基本的なNAT」と「ネットワークアドレス/ポート翻訳（NAPT）」[RFC2663]の両方を含んでいます。用語「NATセッションは、」[NAT-MIB]から適合されており、以下のように定義されます。
NAT Session - A NAT session is an association between a TCP session as seen in the internal realm and a TCP session as seen in the external realm, by virtue of NAT translation. The NAT session will provide the translation glue between the two session representations.
NATセッション - NAT変換によって、外部の領域に見られるように、内部領域とのTCPセッションに見られるようにNATセッションは、TCPセッションの間の関連付けです。 NATセッションは2つのセッション表現の間の変換接着剤を提供します。
This document uses the term "TCP connection" (or just "connection") to refer to individual TCP flows identified by the 4-tuple (source and destination IP address and TCP port) and the initial sequence numbers (ISN).
この文書では、4タプル（送信元および宛先IPアドレスとTCPポート）と初期シーケンス番号（ISN）によって識別されるフロー個々のTCPを指すために、用語「TCP接続」（または単に「接続」）を使用します。
This document uses the term "address and port mapping" (or just "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT necessary for network address and port translation of TCP connections. This document also uses the terms "Endpoint-Independent Mapping", "Address-Dependent Mapping", "Address and Port-Dependent Mapping", "filtering behavior", "Endpoint-Independent Filtering", "Address-Dependent Filtering", "Address and Port-Dependent Filtering", "Port assignment", "Port overloading", "hairpinning", and "External source IP address and port" as defined in [BEHAVE-UDP].
[BEHAVE-UDP]で定義されている。この文書では、ネットワークアドレスとTCP接続のポート変換のために必要なNATの状態を参照するために用語「アドレスとポートマッピング」（または単に「マッピング」）を使用しています。また、このドキュメントでは、用語「エンドポイント・独立マッピング」、「アドレス依存マッピング」、「アドレスとポート依存マッピング」、「フィルタリングの振る舞い」、「エンドポイントに依存しないフィルタリング」、「アドレス依存フィルタリング」、「アドレスを使用していますそして、ポート依存フィルタリング」、 『ポートの割り当て』、 『ポートのオーバーロード』、 『ヘアピン』、および 『外部ソースのIPアドレスとポート』 [BEHAVE-UDP]で定義されています。
This section describes various NAT behaviors applicable to TCP connection initiation.
このセクションでは、TCPコネクションの開始に該当する様々なNATの動作を説明します。
A NAT uses a mapping to translate packets for each TCP connection. A mapping is dynamically allocated for connections initiated from the internal side, and potentially reused for certain subsequent connections. NAT behavior regarding when a mapping can be reused differs for different NATs as described in [BEHAVE-UDP].
NATは、各TCP接続のパケットを変換するためのマッピングを使用しています。マッピングは、動的に内側から開始された接続のために割り当てられ、そして潜在的に特定の後続の接続のために再利用されます。 [BEHAVE-UDP]に記載されるようにマッピングが異なるNATのための異なる再利用することができる場合についてNAT振る舞い。
Consider an internal IP address and TCP port (X:x) that initiates a TCP connection to an external (Y1:y1) tuple. Let the mapping allocated by the NAT for this connection be (X1':x1'). Shortly thereafter, the endpoint initiates a connection from the same (X:x) to an external address (Y2:y2) and gets the mapping (X2':x2') on the NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all values of (Y2:y2), then the NAT is defined to have "Endpoint-Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only when Y2 equals Y1, then the NAT is defined to have "Address-Dependent Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) equals (Y1:y1), possible only for consecutive connections to the same external address shortly after the first is terminated and if the NAT retains state for connections in TIME_WAIT state, then the NAT is defined to have "Address and Port-Dependent Mapping" behavior. This document introduces one additional behavior where (X1':x1') never equals (X2':x2'), that is, for each connection a new mapping is allocated; in such a case, the NAT is defined to have "Connection-Dependent Mapping" behavior.
タプル：外部（Y1 Y1）へのTCP接続を開始：内部IPアドレスとTCPポート（X X）を考えてみましょう。この接続にNATによって割り当てられたマッピングは（「：X1」X1）とします。外部アドレス（Y2：Y2）へ：その後まもなく、エンドポイントが同じ（X X）からの接続を開始し、マッピング（X2「：X2」）を取得するNATに。 （Y2：Y2）のすべての値のために：（ '×2' X2）に等しい：（ '×1' X1）があれば[BEHAVE-UDP]あたりのように、その後、NATは、 "エンドポイント・独立マッピング" の挙動を持つように定義されています。もし（X1「：x1は」）と等しい（X2「：X2」）Y2はY1に等しいときにのみ、その後、NATは、「アドレス依存マッピング」の挙動を持つように定義されています。最初が終了した直後に同じ外部アドレスへの連続的な接続のためとNAT場合、：（Y1 Y1）可能：（Y2 Y2）が等しい場合にのみ、（X1「：x1は」）場合は（「×2」X2）に等しいですTIME_WAIT状態の接続のための状態を保持し、その後、NATは、「アドレスとポート依存マッピング」の挙動を持つように定義されています。 （「：X2」X2）に等しいことはありません：この文書は（「×1」X1）が一つの追加の行動を紹介し、それが新しいマッピングが割り当てられ、各接続のために、です。このような場合には、NATは、「接続依存マッピング」の挙動を持つように定義されています。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for TCP.
REQ-1：NATは、TCPのための「エンドポイント・独立マッピング」振る舞いを持たなければなりません。
Justification: REQ-1 is necessary for UNSAF methods to work. Endpoint-Independent Mapping behavior allows peer-to-peer applications to learn and advertise the external IP address and port allocated to an internal endpoint such that external peers can contact it (subject to the NAT's security policy). The security policy of a NAT is independent of its mapping behavior and is discussed later in Section 4.3. Having Endpoint-Independent Mapping behavior allows peer-to-peer applications to work consistently without compromising the security benefits of the NAT.
正当化：UNSAFメソッドが機能するためにREQ-1が必要です。エンドポイント・独立したマッピングの動作は、ピア・ツー・ピアのアプリケーションが外部ピアがそれに連絡することができるような内部エンドポイント（NATのセキュリティポリシーに従う）に割り当てられた外部IPアドレスとポートを学び、宣伝することができます。 NATのセキュリティポリシーは、そのマッピング動作とは独立しており、4.3節で後述します。エンドポイント・独立したマッピングの挙動を持つことは、ピア・ツー・ピアのアプリケーションがNATのセキュリティ上の利点を損なうことなく、一貫して動作することができます。
An internal endpoint initiates a TCP connection through a NAT by sending a SYN packet. The NAT allocates (or reuses) a mapping for the connection, as described in the previous section. The mapping defines the external IP address and port used for translation of all packets for that connection. In particular, for client-server applications where an internal client initiates the connection to an external server, the mapping is used to translate the outbound SYN, the resulting inbound SYN-ACK response, the subsequent outbound ACK, and other packets for the connection. This method of connection initiation corresponds to the 3-way handshake (defined in [RFC0793]) and is supported by all NATs.
内部エンドポイントは、SYNパケットを送信することにより、NAT経由TCP接続を開始します。前のセクションで説明したようにNAT割り当て（または再利用）接続のためのマッピング。マッピングは、その接続のすべてのパケットの翻訳のために使用される外部IPアドレスとポートを定義します。具体的には、内部クライアントが外部サーバへの接続を開始し、クライアント - サーバアプリケーションのために、マッピングは、接続のためのアウトバウンドSYN、得られた受信SYN-ACK応答を、後続の送信ACK、及び他のパケットを変換するために使用されます。接続開始のこの方法は、（[RFC0793]で定義される）、3ウェイハンドシェイクに相当し、すべてのNATによって支持されています。
Peer-to-peer applications use an alternate method of connection initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse NATs. In the simultaneous-open mode of operation, both peers send SYN packets for the same TCP connection. The SYN packets cross in the network. Upon receiving the other end's SYN packet, each end responds with a SYN-ACK packet, which also cross in the network. The connection is considered established once the SYN-ACKs are received. From the perspective of the NAT, the internal host's SYN packet is met by an inbound SYN packet for the same connection (as opposed to a SYN-ACK packet during a 3-way handshake). Subsequent to this exchange, both an outbound and an inbound SYN-ACK are seen for the connection. Some NATs erroneously block the inbound SYN for the connection in progress. Some NATs block or incorrectly translate the outbound SYN-ACK. Such behavior breaks TCP simultaneous-open and prevents peer-to-peer applications from functioning correctly behind a NAT.
ピア・ツー・ピア・アプリケーションは、接続開始の別の方法を使用した（図8、[RFC0793]）同時オープンと呼ばれるのNATを横断します。操作の同時オープンモードでは、両方のピアが同じTCP接続のSYNパケットを送信します。 SYNパケットは、ネットワーク内で交差しています。もう一方の端のSYNパケットを受信すると、各端部は、ネットワークに交差SYN-ACKパケットで応答します。 SYN-ACKが受信されるとの接続が確立したと見なされます。 （3ウェイハンドシェイク中にSYN-ACKパケットではなく）NATの観点から、内部ホストのSYNパケットは、同じ接続の着信SYNパケットによって満たされます。この交換に続いて、アウトバウンド及びインバウンドSYN-ACKの両方が接続のために見られます。いくつかのNATは誤って進行中の接続のための着信SYNをブロックします。いくつかのNATはブロックしたり、誤って発信SYN-ACKを翻訳します。このような行動は、同時オープンTCPを破壊し、NATの後ろに正しく機能からピアツーピアアプリケーションを防ぐことができます。
In order to provide network address translation service for TCP, it is necessary for a NAT to correctly receive, translate, and forward all packets for a connection that conform to valid transitions of the TCP State-Machine (Fig. 6, [RFC0793]).
NATが正しく、受信変換、およびTCPステートマシンの有効な遷移に準拠接続のすべてのパケットを転送するためにTCPのためのネットワークアドレス変換サービスを提供するために、それが必要である（図6、[RFC0793]） 。
REQ-2: A NAT MUST support all valid sequences of TCP packets (defined in [RFC0793]) for connections initiated both internally as well as externally when the connection is permitted by the NAT. In particular: a) In addition to handling the TCP 3-way handshake mode of connection initiation, A NAT MUST handle the TCP simultaneous-open mode of connection initiation.
REQ-2：NATは、接続がNATによって許可された場合、両方の内部ならびに外部から開始された接続のためのTCPパケット（[RFC0793]で定義される）のすべての有効なシーケンスをサポートしなければなりません。特に：a）の接続開始のTCP 3ウェイハンドシェイクモードの処理に加えて、A NATは、接続開始のTCP同時オープンモードを処理する必要があります。
Justification: The intent of this requirement is to allow standards compliant TCP stacks to traverse NATs no matter what path the stacks take through the TCP state-machine and no matter which end initiates the connection as long as the connection is permitted by the filtering policy of the NAT (filtering policy is described in the following section). a) In addition to TCP packets for a 3-way handshake, A NAT must be prepared to accept an inbound SYN and an outbound SYN-ACK for an internally initiated connection in order to support simultaneous-open.
正当化：この要件の意図は、標準に準拠TCPは関係なく、スタックはTCPステート・マシンと終わりがある限り接続はのフィルタリングポリシーで許可されているように、接続を開始どんなにを通じて取る何パスのNATを通過しないようにスタックできるようにすることですNAT（フィルタリングポリシーは、次のセクションで説明されています）。 a）の3ウェイハンドシェイクのためのTCPパケットに加えて、A NATを同時オープンをサポートするために、内部的に開始した接続のためのインバウンドとアウトバウンドのSYN SYN-ACKを受け入れるように準備しなければなりません。
The NAT allocates a mapping for the first connection initiated by an internal endpoint to an external endpoint. In some scenarios, the NAT's policy may allow this mapping to be reused for connections initiated from the external side to the internal endpoint. Consider as before an internal IP address and port (X:x) that is assigned (or reuses) a mapping (X1':x1') when it initiates a connection to an external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate a connection with the internal endpoint by sending a SYN to (X1':x1'). A NAT can choose to either allow the connection to be established, or to disallow the connection. If the NAT chooses to allow the connection, it translates the inbound SYN and routes it to (X:x) as per the existing mapping. It also translates the SYN-ACK generated by (X:x) in response and routes it to (Y2:y2), and so on. Alternately, the NAT can disallow the connection by filtering the inbound SYN.
NATは、外部エンドポイントに内部エンドポイントによって開始された最初の接続のマッピングを割り当てます。いくつかのシナリオでは、NATの方針は、このマッピングは、内部エンドポイントへの外部側から開始された接続のために再利用されることを可能にします。それは、外部（：Y1 Y1）への接続を開始するとき：割り当てられた（または再利用）されたマッピング（X1「X1」）：（X X）の内部IPアドレスとポート以前のように考えてみましょう。外部エンドポイント（Y2：Y2）は（「：X1」X1）にSYNを送信することによって、内部エンドポイントとの接続を開始しようとします。 NATは、にいずれかを選択し、接続を確立するか、接続を拒否できるようにすることができます。既存のマッピングに従って：NATは接続を許可することを選択した場合、それは、着信SYN及び（X X）へのルートを変換します。ように：（Y2 Y2）、及び（X X）に対応し、ルートそれにまたSYN-ACKにより生成翻訳します。代わりに、NATはインバウンドSYNをフィルタリングすることにより、接続を拒否することができます。
A NAT may allow an existing mapping to be reused by an externally initiated connection if its security policy permits. Several different policies are possible as described in [BEHAVE-UDP]. If a NAT allows the connection initiation from all (Y2:y2), then it is defined to have "Endpoint-Independent Filtering" behavior. If the NAT allows connection initiations only when Y2 equals Y1, then the NAT is defined to have "Address-Dependent Filtering" behavior. If the NAT allows connection initiations only when (Y2:y2) equals (Y1:y1), then the NAT is defined to have "Address and Port-Dependent Filtering" behavior (possible only shortly after the first connection has been terminated but the mapping is still active). One additional filtering behavior defined in this document is when the NAT does not allow any connection initiations from the external side; in such cases, the NAT is defined to have "Connection-Dependent Filtering" behavior. The difference between "Address and Port-Dependent Filtering" and "Connection-Dependent Filtering" behavior is that the former permits an inbound SYN during the TIME_WAIT state of the first connection to initiate a new connection while the latter does not.
NATは、既存のマッピングは、そのセキュリティポリシーが許せば、外部から開始された接続で再利用できるようにすることができます。 [BEHAVE-UDP]で説明したように、いくつかの異なるポリシーが可能です。 NATは、すべて（Y2：Y2）からの接続開始を許可している場合、「エンドポイントに依存しないフィルタリング」の挙動を持つように定義されています。 Y2はY1に等しい場合にのみ、NATは、接続イニシエーションを許可する場合は、NATは、「アドレス依存フィルタリング」の挙動を持つように定義されています。 （Y1：y1）と等しくなり、その後、NATは、最初の接続が終了しただけですぐ後に可能（「アドレスとポート依存フィルタリング」の挙動を持つように定義されていますが、マッピング：NATは、（Y2 Y2）がときに接続イニシエーションのみを許可している場合）まだアクティブです。 NATは、外部から任意の接続のイニシエーションを許可しない場合は、この文書で定義された一つの追加のフィルタリングの動作です。このような場合には、NATは、「接続依存フィルタリング」の挙動を持つように定義されています。 「アドレスとポート依存フィルタリング」と「接続依存フィルタリング」挙動の違いは、後者はそうではない最初の接続のTIME_WAIT状態の間元許可インバウンドSYNが新しい接続を開始することです。
REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior for TCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. b) The filtering behavior for TCP MAY be independent of the filtering behavior for UDP.
REQ-3：アプリケーションの透明性が最も重要である場合には、NATは、TCPのための「エンドポイントに依存しないフィルタリング」行動することをお勧めします。より厳格なフィルタリング動作が最も重要であるならば、NATは、「アドレス依存フィルタリング」の挙動を持っていることが推奨されます。 a）は、フィルタリング動作はNATの管理者が設定オプションの可能性があります。 b）はTCPのためのフィルタリング動作は、UDPのフィルタリング動作の独立していてもよいです。
Justification: The intent of this requirement is to allow peer-to-peer applications that do not always initiate connections from the internal side of the NAT to continue to work in the presence of NATs. This behavior also allows applications behind a BEHAVE compliant NAT to inter-operate with remote endpoints that are behind non-BEHAVE compliant (legacy) NATs. If the remote endpoint's NAT does not have Endpoint-Independent Mapping behavior but has only one external IP address, then an application can still traverse the combination of the two NATs if the local NAT has Address-Dependent Filtering. Section 9 contains a detailed discussion on the security implications of this requirement.
正当化：この要件の意図は、常にNATの存在下で働き続けるためにNATの内側からの接続を開始していないピア・ツー・ピア・アプリケーションを可能にすることです。この動作は、非BEHAVE対応（レガシー）NATの背後にあるリモートエンドポイントと相互運用するアプリケーションBEHAVE対応のNATの背後にできます。リモートエンドポイントのNATは、エンドポイント非依存のマッピングの動作を持っていますが、唯一つの外部IPアドレスを持っていない場合は、ローカルNATは、アドレス依存フィルタリングを持っている場合、そのアプリケーションは、まだ2つのNATの組み合わせを通過することができます。第9章は、この要件のセキュリティへの影響について詳細な議論が含まれています。
If the inbound SYN packet is filtered, either because a corresponding mapping does not exist or because of the NAT's filtering behavior, a NAT has two basic choices: to ignore the packet silently, or to signal an error to the sender. Signaling an error through ICMP messages allows the sender to quickly detect that the SYN did not reach the intended destination. Silently dropping the packet, on the other hand, allows applications to perform simultaneous-open more reliably.
着信SYNパケットがフィルタリングされる場合は、どちらかの対応するマッピングが存在するため、またはNATのフィルタリング動作をしていないため、NATは、2つの基本的な選択肢があります：黙ってパケットを無視する、または送信者にエラーを通知します。 ICMPメッセージによるエラーをシグナリングは、送信者がすぐにSYNが目的の宛先に到達しなかったことを検出することができます。サイレントパケットをドロップし、一方で、アプリケーションをより確実に同時オープンを実行することができます。
Silently dropping the SYN aids simultaneous-open as follows. Consider that the application is attempting a simultaneous-open and the outbound SYN from the internal endpoint has not yet crossed the NAT (due to network congestion or clock skew between the two endpoints); this outbound SYN would otherwise have created the necessary mapping at the NAT to allow translation of the inbound SYN. Since the outbound SYN did not reach the NAT in time, the inbound SYN cannot be processed. If a NAT responds to the premature inbound SYN with an error message that forces the external endpoint to abandon the connection attempt, it hinders applications performing a TCP simultaneous-open. If instead the NAT silently ignores the inbound SYN, the external endpoint retransmits the SYN after a TCP timeout. In the meantime, the NAT creates the mapping in response to the (delayed) outbound SYN such that the retransmitted inbound SYN can be routed and simultaneous-open can succeed. The downside to this behavior is that in the event the inbound SYN is erroneous, the remote side does not learn of the error until after several TCP timeouts.
次のようにサイレント同時オープンSYN補助を落とします。アプリケーションが同時オープンを試みていると内部エンドポイントからのアウトバウンドSYNはまだ（これは2つのエンドポイント間のネットワークの輻輳やクロック・スキュー）NATを越えていないと考えます。このアウトバウンドSYNは、そうでない場合は、着信SYNの翻訳を可能にするために、NATに必要なマッピングを作成しているだろう。アウトバウンドSYNが時間内にNATに到達しなかったので、インバウンドSYNを処理することはできません。 NATは、接続試行を放棄するために外部のエンドポイントを強制的にエラーメッセージとともに、早期の着信SYNに応答した場合、それが同時オープンTCPを実行するアプリケーションを妨げます。代わりに、NATは静かインバウンドSYNを無視した場合、外部エンドポイントはTCPタイムアウト後のSYNを再送します。一方、NATは、再送されたインバウンドのSYNがルーティングされ、同時オープンが成功することができますすることができるように（遅延）アウトバウンドSYNに応じてマッピングを作成します。この動作の欠点は、着信SYNが誤っている場合には、リモート側がするまで、いくつかのTCPのタイムアウト後にエラーを学習しないということです。
NAT support for simultaneous-open as well as quickly signaling errors are both important for applications. Unfortunately, there is no way for a NAT to signal an error without forcing the endpoint to abort a potential simultaneous-open: TCP RST and ICMP Port Unreachable packets require the endpoint to abort the attempt while the ICMP Host and Network Unreachable errors may adversely affect other connections to the same host or network [RFC1122].
オープン同時だけでなく、すぐにエラーを知らせるためのNATサポートは、両方のアプリケーションのために重要です。 TCP RSTやICMPポート到達不能パケットICMPホストとネットワーク到達不能エラーが悪影響を及ぼす可能性がありながら試行を中止するには、エンドポイントが必要です。残念ながら、NATは、潜在的な同時オープンを中止するエンドポイントを強制せずにエラーを通知するための方法はありません同じホストまたはネットワーク[RFC1122]に他の接続。
In addition, when an unsolicited SYN is received by the NAT, the NAT may not know whether the application is attempting a simultaneous-open (and that it should therefore silently drop the SYN) or whether the SYN is in error (and that it should notify the sender).
迷惑SYNがNATによって受信された場合に加えて、NATは、アプリケーションが同時オープンを試みる（そしてそれは、したがってサイレントSYNをドロップする必要があること）、またはSYNがエラーであるか否か（それがなければならないということであるかどうかわからないかもしれません）送信者に通知。
REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet for at least 6 seconds after the packet is received. If during this interval the NAT receives and translates an outbound SYN for the connection the NAT MUST silently drop the original unsolicited inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original SYN, unless REQ-4a applies. a) The NAT MUST silently drop the original SYN packet if sending a response violates the security policy of the NAT.
REQ-4：パケットを受信した後、NATは、少なくとも6秒間不要な受信SYNパケットに応じてはいけません。このインターバルの間にNATが受信して、接続のためのアウトバウンドSYNを変換する場合はNATは黙って、元の未承諾の着信SYNパケットをドロップしなければなりません。 REQ-4Aが適用される場合を除き、それ以外の場合は、NATは、オリジナルのSYNのためにICMPポート到達不能エラー（タイプ3、コード3）を送信すべきです。応答を送信すると、NATのセキュリティポリシーに違反している場合a）のNATは黙って、元のSYNパケットをドロップしなければなりません。
Justification: The intent of this requirement is to allow simultaneous-open to work reliably in the presence of NATs as well as to quickly signal an error in case the unsolicited SYN is in error. As of writing this memo, it is not possible to achieve both; the requirement therefore represents a compromise. The NAT should tolerate some delay in the outbound SYN for a TCP simultaneous-open, which may be due to network congestion or loose synchronization between the endpoints. If the unsolicited SYN is not part of a simultaneous-open attempt and is in error, the NAT should endeavor to signal the error in accordance with [RFC1122]. a) There may, however, be reasons for the NAT to rate-limit or omit such error notifications, for example, in the case of an attack. Silently dropping the SYN packet when under attack allows simultaneous-open to work without consuming any extra network bandwidth or revealing the presence of the NAT to attackers. Section 9 mentions the security considerations for this requirement.
正当化：この要件の目的は同時オープンのNATの存在下で確実に動作するだけでなく、迅速に迷惑SYNが誤っている場合にエラーを通知できるようにすることです。このメモを書くと、両方を達成することはできません。要件は、そのための妥協を表しています。 NATは、ネットワークの輻輳やエンドポイント間の緩い同期であることができる同時オープンTCP、発信のためのSYNでいくつかの遅延を許容すべきです。迷惑SYNが同時オープンの試みの一部ではなく、エラーになっている場合、NATは、[RFC1122]に従ってエラーを通知するよう努めなければなりません。 A）、しかし、レートリミットや攻撃の場合には、例えば、エラー通知を省略するNATの理由があってもよいです。攻撃を受けて同時オープンが余分なネットワーク帯域幅を消費するか、攻撃者へのNATの存在を明らかにすることなく作業することができたときにサイレントSYNパケットをドロップします。第9章は、この要件のためのセキュリティの考慮事項を記載しています。
For NATs that combine NAT functionality with end-host functionality (e.g., an end-host that also serves as a NAT for other hosts behind it), REQ-4 above applies only to SYNs intended for the NAT'ed hosts and not to SYNs intended for the NAT itself. One way to determine whether the inbound SYN is intended for a NAT'ed host is to allocate NAT mappings from one port range, and allocate ports for local endpoints from a different non-overlapping port range. More dynamic implementations can be imagined.
エンドホストの機能とNAT機能を組み合わせるNATのための（例えば、また、その背後にある他のホストに対するNATとして機能するエンドホスト）は、REQ-4は、上記のSYNにNATによるホストを意図のSYNにのみ適用されませんNAT自身のために意図。インバウンドSYNがNATによるホストのために意図されているかどうかを決定するための一つの方法は、1つのポート範囲からNATマッピングを割り当て、異なる非重複ポート範囲からローカルエンドポイントのポートを割り当てることです。より動的な実装では、想像することができます。
A NAT maintains state associated with in-progress and established connections. Because of this, a NAT is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the internal side attempts to cause the NAT to create more state than for which it has resources. To prevent such an attack, a NAT needs to abandon sessions in order to free the state resources.
NATは進行中と確立された接続に関連付けられた状態を維持しています。このため、NATは、そのためには、リソースを持っているよりも内部側の攻撃者（またはウイルス）NATがより多くの状態を作成させるためにしようとすることにより、資源枯渇の攻撃を受けやすいです。このような攻撃を防ぐために、NATは、状態のリソースを解放するためにセッションを放棄する必要があります。
A common method that is applicable only to TCP is to preferentially abandon sessions for crashed endpoints, followed by closed TCP connections and partially open connections. A NAT can check if an endpoint for a session has crashed by sending a TCP keep-alive packet and receiving a TCP RST packet in response. If the NAT cannot determine whether the endpoint is active, it should not abandon the session until the TCP connection has been idle for some time. Note that an established TCP connection can stay idle (but live) indefinitely; hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC1122] can reduce the chances of abandoning a live session.
TCPだけに適用される一般的な方法は、閉じたTCP接続と、部分的にオープンな接続に続いて、優先的にクラッシュしたエンドポイントのセッションを放棄することです。セッションのエンドポイントは、TCPキープアライブパケットを送信し、それに応答してTCP RSTパケットを受信することにより、クラッシュした場合、NATが確認できます。 NATは、エンドポイントがアクティブであるかどうかを判断できない場合は、TCP接続がしばらくの間アイドル状態になっているまで、それはセッションを放棄するべきではありません。確立されたTCP接続が無期限にアイドル状態のまま（しかし生きる）できることに注意してください。したがって、すべてのアプリケーションを収容するアイドルタイムアウトのための固定値は存在しません。しかしながら、[RFC1122]の推奨事項によって動機付け大アイドルタイムアウトは、ライブセッションを放棄する可能性を低減することができます。
A TCP connection passes through three phases: partially open, established, and closing. During the partially open phase, endpoints synchronize initial sequence numbers. The phase is initiated by the first SYN for the connection and extends until both endpoints have sent a packet with the ACK flag set (TCP states: SYN_SENT and SYN_RCVD). ACKs in both directions mark the beginning of the established phase where application data can be exchanged indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and CLOSE_WAIT). The closing phase begins when both endpoints have terminated their half of the connection by sending a FIN packet. Once FIN packets are seen in both directions, application data can no longer be exchanged, but the stacks still need to ensure that the FIN packets are received (TCP states: CLOSING and LAST_ACK).
部分的に開いて、確立、およびクロージング：TCP接続の3つのフェーズを通過します。部分的にオープンなフェーズでは、エンドポイントは、初期シーケンス番号を同期させます。位相が接続するための第1のSYNによって開始され、両方のエンドポイントは、ACKフラグを設定してパケットを送信するまで延びている（TCP状態：SYN_SENTとSYN_RCVD）。両方向のACKは、アプリケーションデータを無期限に交換することができる確立相（：ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、およびCLOSE_WAIT TCP状態）の始まりをマーク。両方のエンドポイントがFINパケットを送信することにより、接続の彼らの半分を終了した時に閉鎖段階が開始されます。 FINパケットが両方向に見られていると、アプリケーション・データがもはや交換することはできないが、スタックはまだFINパケットが受信されていることを確認する必要があります（TCPの状態：CLOSINGとLAST_ACK）。
TCP connections can stay in established phase indefinitely without exchanging any packets. Some end-hosts can be configured to send keep-alive packets on such idle connections; by default, such keep-alive packets are sent every 2 hours if enabled [RFC1122]. Consequently, a NAT that waits for slightly over 2 hours can detect idle connections with keep-alive packets being sent at the default rate. TCP connections in the partially open or closing phases, on the other hand, can stay idle for at most 4 minutes while waiting for in-flight packets to be delivered [RFC1122].
TCP接続は、任意のパケットを交換することなく、無期限に確立フェーズに滞在することができます。いくつかのエンドホストは、アイドル状態の接続にキープアライブパケットを送信するように設定することができます。デフォルトでは、そのようなキープアライブパケットは、[RFC1122]を有効にした場合、2時間ごとに送信されます。その結果、キープアライブパケットでアイドル状態の接続を検出することができ、わずか2時間以上待つNATは、デフォルトのレートで送信されます。配信される飛行中のパケットを待っている間に、部分的に開いたり閉じ段階でのTCP接続は、他の一方で、[RFC1122]でほとんどの4分間アイドル状態に滞在することができます。
The "established connection idle-timeout" for a NAT is defined as the minimum time a TCP connection in the established phase must remain idle before the NAT considers the associated session a candidate for removal. The "transitory connection idle-timeout" for a NAT is defined as the minimum time a TCP connection in the partially open or closing phases must remain idle before the NAT considers the associated session a candidate for removal. TCP connections in the TIME_WAIT state are not affected by the "transitory connection idle-timeout".
NATのための「確立された接続のアイドルタイムアウト」NATは関連するセッションに除去するための候補者を検討する前に確立フェーズにおけるTCP接続がアイドル状態のままでなければならない最小の時間として定義されます。 NATのための「一時接続アイドルタイムアウトは、」NATは関連するセッションに除去するための候補者を検討する前に、部分的に開いたり閉じ段階でのTCP接続がアイドル状態のままでなければならない最小の時間として定義されます。 TIME_WAIT状態のTCP接続は、「一時的な接続アイドルタイムアウト」の影響を受けません。
REQ-5: If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than 4 minutes. a) The value of the NAT idle-timeouts MAY be configurable.
REQ-5：NATは、TCP接続のエンドポイントがアクティブであるかどうかを判断できない場合は、しばらくの間アイドル状態になっている場合、それはセッションを放棄することができます。このような場合、「確立された接続アイドルタイムアウト」の値が2時間未満で4分であってはいけません。 「一時的な接続アイドルタイムアウト」の値が4分以上でなければなりません。 A）NATアイドルタイムアウトの値が設定可能です。
Justification: The intent of this requirement is to minimize the cases where a NAT abandons session state for a live connection. While some NATs may choose to abandon sessions reactively in response to new connection initiations (allowing idle connections to stay up indefinitely in the absence of new initiations), other NATs may choose to proactively reap idle sessions. In cases where the NAT cannot actively determine if the connection is alive, this requirement ensures that applications can send keep-alive packets at the default rate (every 2 hours) such that the NAT can passively determine that the connection is alive. The additional 4 minutes allows time for in-flight packets to cross the NAT.
正当化：この要件の意図は、NATは、ライブ接続のセッション状態を放棄する例を最小限に抑えることです。いくつかのNATは、（アイドル接続は、新しいイニシエーションの不存在下で無期限まで滞在することができます）新しい接続のイニシエーションに応じて、反応性のセッションを放棄することを選択するかもしれないが、他のNATは積極的にアイドル状態のセッションを享受することもできます。接続が生きているかどうNATを積極的に決定することができない場合には、この要件は、NATは、受動的な接続が生きていることを判断することができるようなアプリケーションは、デフォルトのレートで（2時間ごとに）キープアライブパケットを送信できることを保証します。さらに4分間飛行中のパケットはNATを横断するための時間を確保できます。
NAT behavior for handling RST packets, or connections in TIME_WAIT state is left unspecified. A NAT MAY hold state for a connection in TIME_WAIT state to accommodate retransmissions of the last ACK. However, since the TIME_WAIT state is commonly encountered by internal endpoints properly closing the TCP connection, holding state for a closed connection may limit the throughput of connections through a NAT with limited resources. [RFC1337] describes hazards associated with TIME_WAIT assassination.
TIME_WAIT状態でRSTパケット、または接続を処理するためのNATの動作は未指定のままにされます。 NATは、最後のACKの再送信に対応するために、TIME_WAIT状態での接続のための状態を保持することができます。しかし、TIME_WAIT状態は、一般に適切に限られたリソースとのNATを介して接続のスループットが制限される可能性が閉じられた接続の状態を保持し、TCP接続を閉じる内部エンドポイントによって検出されたからです。 [RFC1337]はTIME_WAITの暗殺に伴う危険について説明します。
The handling of non-SYN packets for connections for which there is no active mapping is left unspecified. Such packets may be received if the NAT silently abandons a live connection, or abandons a connection in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The decision to either silently drop such packets or to respond with a TCP RST packet is left up to the implementation.
アクティブなマッピングが存在しないいる接続のための非SYNパケットの処理が指定されていないままです。 NATは静かライブ接続を放棄、又は期間が満了するTIME_WAIT 4分前にTIME_WAIT状態で接続を破棄場合、このようなパケットが受信されてもよいです。静かにそのようなパケットをドロップするか、またはTCP RSTパケットで応答する決定は実装に任されています。
NAT behavior for notifying endpoints when abandoning live connections is left unspecified. When a NAT abandons a live connection, for example due to a timeout expiring, the NAT MAY either send TCP RST packets to the endpoints or MAY silently abandon the connection.
ライブ接続を放棄する場合、エンドポイントを通知するためのNAT動作は不定に残っています。 NATが原因期限切れタイムアウトに例えば、ライブ接続を放棄する場合、NATは、エンドポイントへのTCP RSTパケットを送るかもしれいずれか、または静かに接続を放棄することができます。
Sending a RST notification allows endpoint applications to recover more quickly; however, notifying the endpoints may not always be possible if, for example, session state is lost due to a power failure.
RST通知を送信するエンドポイントのアプリケーションをより迅速に回復することができます。例えば、セッションの状態は電源障害が原因で失われた、ただし、エンドポイントに通知することは常に可能ではないかもしれません。
Application Level Gateways (ALGs) in certain NATs modify IP addresses and TCP ports embedded inside application protocols. Such ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and must therefore be used with extreme caution.
アプリケーションレベルゲートウェイ（のALG）特定のNATの内のアプリケーション・プロトコル内に埋め込まれたIPアドレスとTCPポートを変更します。このようなのALGは、NAT-注意してしようとし、したがって、細心の注意を払って使用する必要がありますUNSAFメソッドまたはプロトコルを妨げる可能性があります。
REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP [RFC0959]) be disabled by default.
REQ-6：NATは、TCPに影響を与えるのALGが含まれている場合、それらのALGのすべて（FTPを除き、[RFC0959]）はデフォルトで無効にすることをお勧めします。
Justification: The intent of this requirement is to prevent ALGs from interfering with UNSAF methods. The default state of an FTP ALG is left unspecified because of legacy concerns: as of writing this memo, a large fraction of legacy FTP clients do not enable passive (PASV) mode by default and require an ALG to traverse NATs.
正当化：この要件の目的は、UNSAF方法に干渉のALGを防止するためです。 FTP ALGのデフォルト状態があるため、従来の懸念を未指定のままにされています。このメモを書くように、従来のFTPクライアントの大部分は、デフォルトでパッシブ（PASV）モードを有効にして、NATのを横断するALGを必要としません。
A list of general and UDP-specific NAT behavioral requirements are described in [BEHAVE-UDP]. A list of ICMP-specific NAT behavioral requirements are described in [BEHAVE-ICMP]. The requirements listed below reiterate the requirements from these two documents that directly affect TCP. The following requirements do not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
一般的およびUDP固有のNATの行動要件のリストは、[BEHAVE-UDP]で説明されています。 ICMP特有のNATの行動要件のリストは、[BEHAVE-ICMP]で説明されています。以下の要件は、直接TCPに影響を与えるこれら二つの文書からの要求を繰り返します。次の要件が[BEHAVE-UDP]または[BEHAVE-ICMP]のいずれかの要件を緩和していません。
NATs that allow different internal endpoints to simultaneously use the same mapping are defined in [BEHAVE-UDP] to have a "Port assignment" behavior of "Port overloading". Such behavior is undesirable, as it prevents two internal endpoints sharing the same mapping from establishing simultaneous connections to a common external endpoint.
異なる内部エンドポイントが同時に同じマッピングを使用することを可能にするNATは、「ポートのオーバーロード」の「ポートの割り当て」挙動を有するように[BEHAVE-UDP]で定義されています。それは共通の外部エンドポイントへの同時接続を確立同じマッピングを共有する二つの内部エンドポイントを防止するような挙動は、望ましくありません。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for TCP.
REQ-7：NATはTCPについては、「ポートのオーバーロード」の「ポートの割り当て」の動作を持ってはいけません。
Justification: This requirement allows two applications on the internal side of the NAT to consistently communicate with the same destination.
正当化：この要件は、NATの内側に2つのアプリケーションが一貫して同一の宛先と通信することを可能にします。
NAT behavior for preserving the source TCP port range for connections is left unspecified. Some applications expect the source TCP port to be in the well-known range (TCP ports from 0 to 1023). The "r" series of commands (rsh, rcp, rlogin, etc.) are an example. NATs that preserve the range from which the source port is picked allow such applications to function properly through the NAT; however, by doing so the NAT may compromise the security of the application in certain situations; applications that depend only on the IP address and source TCP port range for security (the "r" commands, for example) cannot distinguish between an attacker and a legitimate user behind the same NAT.
接続の送信元TCPポートの範囲を保存するためのNAT動作は不定に残っています。一部のアプリケーションでは、送信元TCPポートは、よく知られている範囲（0から1023 TCPポート）であることを期待します。コマンドの "R" シリーズ（RSH、RCP、rloginの、など）が例です。ソースポートは、アプリケーションがNATを介して正常に機能することを可能に採取された範囲を維持するNAT。しかし、特定の状況で、アプリケーションのセキュリティを損なう可能性があるので、NATを実行して、 （例えば、「R」コマンド）のみセキュリティのためのIPアドレスと送信元TCPポート範囲に依存するアプリケーションは、攻撃者と同じNATの背後にある正規のユーザを区別できません。
NATs that forward packets originating from an internal address, destined for an external address that matches the active mapping for an internal address, back to that internal address are defined in [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the hairpinned packet with an external source IP address and port (i.e., the mapped source address and port of the originating internal endpoint), then it is defined to have "External source IP address and port" for hairpinning. Hairpinning is necessary to allow two internal endpoints (known to each other only by their external mapped addresses) to communicate with each other. "External source IP address and port" behavior for hairpinning avoids confusing implementations that expect the external source IP address and port.
内部アドレスのアクティブ・マッピングに一致する外部アドレス宛の内部アドレスから発信パケットを転送するNATは、バックその内部アドレスには「ヘアピン」を支持するようBEHAVE-UDP]で定義されています。 NATは、外部ソースIPアドレスとポート（元の内部エンドポイントの、すなわち、マッピングされた送信元アドレスとポート）を持つヘアピンパケットを提示した場合、ヘアピンのために「外部送信元IPアドレスとポート」を有すると定義されます。ヘアピンは、（のみその外部マッピングされたアドレスによってお互いに知られている）は、2つの内部のエンドポイントが互いに通信することを可能にするのに必要です。ヘアピンのための「外部ソースIPアドレスとポート」の動作は、外部ソースのIPアドレスとポートを期待する混乱の実装を避けることができます。
REQ-8: A NAT MUST support "hairpinning" for TCP. a) A NAT's hairpinning behavior MUST be of type "External source IP address and port".
REQ-8：NATは、TCPのための "ヘアピン" をサポートしなければなりません。 a）のA NATのヘアピンの動作はタイプ「外部ソースのIPアドレスとポート」でなければなりません。
Justification: This requirement allows two applications behind the same NAT that are trying to communicate with each other using their external addresses. a) Using the external source address and port for the hairpinned packet is necessary for applications that do not expect to receive a packet from a different address than the external address they are trying to communicate with.
正当化：この要件は、彼らの外部アドレスを使用して相互に通信しようとしている同じNATの背後にある二つのアプリケーションを可能にします。 a）はヘアピンパケットのための外部ソースアドレスとポートを使用すると、彼らはと通信しようとしている外部アドレスとは異なるアドレスからのパケットを受け取ることを期待していないアプリケーションのために必要です。
Several TCP mechanisms depend on the reception of ICMP error messages triggered by the transmission of TCP segments. One such mechanism is path MTU discovery [RFC1191], which is required for the correct
いくつかのTCPメカニズムはTCPセグメントの送信によってトリガICMPエラーメッセージの受信に依存します。一つのそのような機構は、正しいために必要とされるパスMTU探索[RFC1191]であります
operation of TCP. The current path MTU discovery mechanism requires the sender of TCP segments to be notified of ICMP "Datagram Too Big" responses.
TCPの動作。現在のパスMTUディスカバリメカニズムは、ICMP「データグラムが大きすぎます」応答を通知するTCPセグメントの送信者を必要とします。
REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
REQ-9：NATは、TCPを変換する場合は、ICMP宛先到達不能（タイプ3）メッセージを翻訳すべきです。
Justification: Translating ICMP Destination Unreachable messages, particularly the "Fragmentation Needed and Don't Fragment was Set" (Type 3, Code 4) message avoids communication failures ("black holes" [RFC2923]). Furthermore, TCP's connection establishment and maintenance mechanisms also behave much more efficiently when ICMP Destination Unreachable messages arrive in response to outgoing TCP segments.
正当化：翻訳ICMP宛先到達不能メッセージを、特に「フラグメンテーション必要と断片をセットしないでください」（タイプ3、コード4）は、メッセージは、通信障害（「ブラックホール」[RFC2923]）を回避します。 ICMP宛先到達不能メッセージが発信TCPセグメントに対応して到着したときにさらに、TCPのコネクションの確立と維持のメカニズムもはるかに効率的に動作します。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated.
REQ-10：ICMPメッセージの任意の並べ替えの領収書は、ICMPが生成されたNATマッピングまたはTCP接続を終了してはなりません。
Justification: This is necessary for reliably performing TCP simultaneous-open where a remote NAT may temporarily signal an ICMP error.
正当化：これは、確実に、リモートのNATが一時的にICMPエラーをシグナリングすることができるTCP同時オープンを行うために必要です。
A NAT that supports all of the mandatory requirements of this specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], is "compliant with this specification". A NAT that supports all of the requirements of this specification (i.e., included the "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully compliant with all the mandatory and recommended requirements of this specification".
本明細書（すなわち、「MUST」）の必須の要件のすべてをサポートし、[BEHAVE-UDP]に準拠しているNATは、「この仕様に準拠」です。この仕様の要件の全てをサポートする（すなわち、「推奨」を含む）と[BEHAVE-UDP]に完全に準拠してNAT「は、本明細書のすべての必須および推奨要件に完全に準拠」です。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for TCP.
REQ-1：NATは、TCPのための「エンドポイント・独立マッピング」振る舞いを持たなければなりません。
REQ-2: A NAT MUST support all valid sequences of TCP packets (defined in [RFC0793]) for connections initiated both internally as well as externally when the connection is permitted by the NAT. In particular: a) In addition to handling the TCP 3-way handshake mode of connection initiation, A NAT MUST handle the TCP simultaneous-open mode of connection initiation.
REQ-2：NATは、接続がNATによって許可された場合、両方の内部ならびに外部から開始された接続のためのTCPパケット（[RFC0793]で定義される）のすべての有効なシーケンスをサポートしなければなりません。特に：a）の接続開始のTCP 3ウェイハンドシェイクモードの処理に加えて、A NATは、接続開始のTCP同時オープンモードを処理する必要があります。
REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior for TCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior.
REQ-3：アプリケーションの透明性が最も重要である場合には、NATは、TCPのための「エンドポイントに依存しないフィルタリング」行動することをお勧めします。より厳格なフィルタリング動作が最も重要であるならば、NATは、「アドレス依存フィルタリング」の挙動を持っていることが推奨されます。
a) The filtering behavior MAY be an option configurable by the administrator of the NAT. b) The filtering behavior for TCP MAY be independent of the filtering behavior for UDP.
a）は、フィルタリング動作はNATの管理者が設定オプションの可能性があります。 b）はTCPのためのフィルタリング動作は、UDPのフィルタリング動作の独立していてもよいです。
REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet for at least 6 seconds after the packet is received. If during this interval the NAT receives and translates an outbound SYN for the connection the NAT MUST silently drop the original unsolicited inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original SYN, unless REQ-4a applies. a) The NAT MUST silently drop the original SYN packet if sending a response violates the security policy of the NAT.
REQ-4：パケットを受信した後、NATは、少なくとも6秒間不要な受信SYNパケットに応じてはいけません。このインターバルの間にNATが受信して、接続のためのアウトバウンドSYNを変換する場合はNATは黙って、元の未承諾の着信SYNパケットをドロップしなければなりません。 REQ-4Aが適用される場合を除き、それ以外の場合は、NATは、オリジナルのSYNのためにICMPポート到達不能エラー（タイプ3、コード3）を送信すべきです。応答を送信すると、NATのセキュリティポリシーに違反している場合a）のNATは黙って、元のSYNパケットをドロップしなければなりません。
REQ-5: If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than 4 minutes. a) The value of the NAT idle-timeouts MAY be configurable.
REQ-5：NATは、TCP接続のエンドポイントがアクティブであるかどうかを判断できない場合は、しばらくの間アイドル状態になっている場合、それはセッションを放棄することができます。このような場合、「確立された接続アイドルタイムアウト」の値が2時間未満で4分であってはいけません。 「一時的な接続アイドルタイムアウト」の値が4分以上でなければなりません。 A）NATアイドルタイムアウトの値が設定可能です。
REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP [RFC0959]) be disabled by default.
REQ-6：NATは、TCPに影響を与えるのALGが含まれている場合、それらのALGのすべて（FTPを除き、[RFC0959]）はデフォルトで無効にすることをお勧めします。
The following requirements reiterate requirements from [BEHAVE-UDP] or [BEHAVE-ICMP] that directly affect TCP. This document does not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
次の要件は、直接TCPに影響を与える[BEHAVE-UDP]または[BEHAVE-ICMP]からの要求を繰り返します。この文書では、[BEHAVE-UDP]または[BEHAVE-ICMP]のいずれかの要件を緩和しません。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for TCP.
REQ-7：NATはTCPについては、「ポートのオーバーロード」の「ポートの割り当て」の動作を持ってはいけません。
REQ-8: A NAT MUST support "hairpinning" for TCP. a) A NAT's hairpinning behavior MUST be of type "External source IP address and port".
REQ-8：NATは、TCPのための "ヘアピン" をサポートしなければなりません。 a）のA NATのヘアピンの動作はタイプ「外部ソースのIPアドレスとポート」でなければなりません。
REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
REQ-9：NATは、TCPを変換する場合は、ICMP宛先到達不能（タイプ3）メッセージを翻訳すべきです。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated.
REQ-10：ICMPメッセージの任意の並べ替えの領収書は、ICMPが生成されたNATマッピングまたはTCP接続を終了してはなりません。
[BEHAVE-UDP] discusses security considerations for NATs that handle IP and unicast UDP traffic. Security concerns specific to handling TCP packets are discussed in this section.
[BEHAVE-UDP]はIPユニキャストUDPトラフィックを処理するNATのセキュリティの考慮事項について説明します。 TCPパケットを処理する特定のセキュリティ上の懸念は、このセクションで説明されています。
Security considerations for REQ-1: This requirement does not introduce any TCP-specific security concerns.
REQ-1のためのセキュリティの考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。
Security considerations for REQ-2: This requirement does not introduce any TCP-specific security concerns. Simultaneous-open and other transitions in the TCP state machine are by-design and necessary for TCP to work correctly in all scenarios. Further, this requirement only affects connections already in progress as authorized by the NAT in accordance with its policy.
REQ-2のためのセキュリティの考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。 TCPステートマシンで、同時オープンし、他の遷移は、TCPは、すべてのシナリオで正しく動作するためにバイ・デザインと必要です。その方針に基づき、NATによって認可としてさらに、この要件は、すでに進行中の接続に影響します。
Security considerations for REQ-3: The security provided by the NAT is governed by its filtering behavior as addressed in [BEHAVE-UDP]. Connection-Dependent Filtering behavior is most secure from a firewall perspective, but severely restricts connection initiations through a NAT. Endpoint-Independent Filtering behavior, which is most transparent to applications, requires an attacker to guess the IP address and port of an active mapping in order to get his packet to an internal host. Address-Dependent Filtering, on the other hand, is less transparent than Endpoint-Independent Filtering but more transparent than Connection-Dependent Filtering; it is more secure than Endpoint-Independent Filtering as it requires an attacker to additionally guess the address of the external endpoint for a NAT session associated with the mapping and be able to receive packets addressed to the same. While this protects against most attackers on the Internet, it does not necessarily protect against attacks that originate from behind a remote NAT with a single IP address that is also translating a legitimate connection to the victim.
REQ-3のためのセキュリティの考慮事項：[BEHAVE-UDP]で取り組まとしてNATによって提供されるセキュリティは、そのフィルタリング動作によって支配されています。接続依存フィルタリングの動作は、ファイアウォールの観点から最も安全ですが、深刻なNAT経由の接続イニシエーションを制限します。アプリケーションに最も透明であるエンドポイントに依存しないフィルタリングの動作は、内部ホストに自分のパケットを取得するために、アクティブ・マッピングのIPアドレスとポートを推測するために、攻撃者が必要です。アドレス依存フィルタリングは、他の一方で、エンドポイントに依存しないフィルタリング未満透明性が、接続依存フィルタリングよりも透明です。それは同じ宛さらにマッピングに関連付けられたNATセッションのための外部のエンドポイントのアドレスを推測し、パケットを受信することができるように、攻撃者を必要とすることは、エンドポイント非依存フィルタリングよりも安全です。これは、インターネット上で最も攻撃から保護しますが、それは必ずしも、また、被害者への正当な接続を翻訳された単一のIPアドレスを持つリモートNAT背後の攻撃からコンピュータを保護することはできません。
Security considerations for REQ-4: This document recommends that a NAT respond to unsolicited inbound SYN packets with an ICMP error delayed by a few seconds. Doing so may reveal the presence of a NAT to an external attacker. Silently dropping the SYN makes it harder to diagnose network problems and forces applications to wait for the TCP stack to finish several retransmissions before reporting an error. An implementer must therefore understand and carefully weigh the effects of not sending an ICMP error or rate-limiting such ICMP errors to a very small number.
REQ-4のためのセキュリティの考慮事項：この文書では、NATが数秒遅れで表示ICMPエラーと不要な受信SYNパケットに応答することをお勧めします。そうすることで、外部の攻撃者にNATの存在を明らかにすることができます。サイレントSYNをドロップすると、それは難しいTCPスタックがエラーを報告する前に、いくつかの再送信を終了するのを待つために、ネットワークの問題と軍のアプリケーションを診断することができます。実装者は、したがって、理解し、慎重に非常に小さな数にICMPエラーや速度制限などICMPエラーを送信しないの効果を比較検討しなければなりません。
Security considerations for REQ-5: This document recommends that a NAT that passively monitors TCP state keep idle sessions alive for at least 2 hours 4 minutes or 4 minutes depending on the state of the connection. If a NAT is under attack, it may attempt to actively determine the liveliness of a TCP connection or let the NAT administrator configure more conservative timeouts.
REQ-5のためのセキュリティの考慮事項：この文書では、受動的にTCPの状態を監視し、NATは、接続の状態に応じて、少なくとも2時間4分または4分生きているアイドル状態のセッションを維持することをお勧めします。 NATが攻撃を受けている場合、それは積極的にTCPコネクションの活気を決定またはNAT管理者はより保守的なタイムアウトを設定できるように試みることができます。
Security considerations for REQ-6: This requirement does not introduce any TCP-specific security concerns.
REQ-6のためのセキュリティの考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。
Security considerations for REQ-7: This requirement does not introduce any TCP-specific security concerns.
REQ-7のセキュリティの考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。
Security considerations for REQ-8: This requirement does not introduce any TCP-specific security concerns.
REQ-8のセキュリティ上の考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。
Security considerations for REQ-9: This requirement does not introduce any TCP-specific security concerns.
REQ-9のためのセキュリティの考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。
Security considerations for REQ-10: This requirement does not introduce any TCP-specific security concerns.
REQ-10のためのセキュリティの考慮事項：この要件は、任意のTCP固有のセキュリティ上の懸念を導入していません。
NAT implementations that modify TCP sequence numbers (e.g., for privacy reasons or for ALG support) must ensure that TCP packets with Selective Acknowledgement (SACK) notifications [RFC2018] are properly handled.
TCPシーケンス番号を変更するNAT実装（例えば、プライバシー上の理由またはALGをサポートするための）選択確認応答（SACK）通知[RFC2018]とそのTCPパケットが正しく処理されることを保証しなければなりません。
NAT implementations that modify local state based on TCP flags in packets must ensure that out-of-window TCP packets are properly handled. [RFC4953] summarizes and discusses a variety of solutions designed to prevent attackers from affecting TCP connections.
パケット内のTCPフラグに基づいて、ローカル状態を変更するNAT実装は、アウト・オブ・ウィンドウTCPパケットが適切に処理されていることを確認する必要があります。 [RFC4953]は要約し、TCPコネクションに影響を与えることから、攻撃を防ぐために設計された様々なソリューションについて説明します。
Joe Touch contributed the mechanism for handling unsolicited inbound SYNs. Thanks to Mark Allman, Francois Audet, Lars Eggert, Paul Francis, Fernando Gont, Sam Hartman, Paul Hoffman, Dave Hudson, Cullen Jennings, Philip Matthews, Tom Petch, Magnus Westerlund, and Dan Wing for their many contributions, comments, and suggestions.
ジョー・タッチは、未承諾のインバウンドのSYNを処理するためのメカニズムを提供しました。彼らの多くの貢献、コメント、および提案のためのマーク・オールマン、フランソワAudet、ラースEggertの、ポール・フランシス、フェルナンドGont、サム・ハートマン、ポール・ホフマン、デイブ・ハドソン、カレン・ジェニングス、フィリップ・マシューズ、トム・ペッチ、マグヌスウェスター、そしてダン・ウィングのおかげで。
[BEHAVE-UDP] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEHAVE-UDP] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]ポステル、J.、およびJ.レイノルズ、 "ファイル転送プロトコル"、STD 9、RFC 959、1985年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[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月。
[BEHAVE-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, June 2008.
[BEHAVE-ICMP] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、進歩、2008年6月、ワーク "ICMPプロトコルのNAT行動要件"。
[NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[NAT-MIB]のRohit、R.、Srisuresh、P.、Raghunarayan、R.、パイ、N.、およびC.王、2005年3月、RFC 4008 "ネットワークのための管理オブジェクトの定義は、翻訳者（NAT）をアドレス"。
[NATBLASTER] Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, "NATBLASTER: Establishing TCP connections between hosts behind NATs", Proceedings of the ACM SIGCOMM Asia Workshop (Beijing, China), April 2005.
[NATBLASTER] Biggadike、A.、Ferullo、D.、ウィルソン、G.、およびA. Perrig、 "NATBLASTER：NATの背後にあるホスト間のTCPコネクションの確立"、ACM SIGCOMMアジアワークショップ（北京、中国）、2005年4月の議事録。
[P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer communication across network address translators", Proceedings of the USENIX Annual Technical Conference (Anaheim, CA), April 2005.
【P2PNAT】フォード、B.、Srisuresh、P.、およびD.ケーゲル、「ネットワークアドレス変換を横切るピア・ツー・ピア通信」、USENIX年次技術会議（アナハイム、CA）の議事録、2005年4月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
"TCPでのTIME-WAITの暗殺の危険" [RFC1337]ブレーデン、B.、RFC 1337、1992年5月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]ブレーデン、B.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[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月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[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月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]デューク、M.、ブレーデン、R.、エディ、W.、及びE.ブラントン、RFC 4614、2006年9月 "伝送制御プロトコル（TCP）仕様書のためのロードマップ"。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]タッチ、J.、RFC 4953、2007年7月 "なりすまし攻撃に対するTCPを防衛"。
[STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach to UDP and TCP connectivity", Proceedings of the ACM SIGCOMM Workshop on Future Directions in Network Architecture (Portland, OR), August 2004.
[STUNT]グハ、S.とP.フランシス、「NUTSS：UDPとTCPの接続にSIPベースのアプローチ」、ネットワークアーキテクチャ（オレゴン州ポートランド）、2004年8月今後の方向性についてACM SIGCOMMワークショップの議事。
[TCPTRAV] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of the Internet Measurement Conference (Berkeley, CA), October 2005.
[TCPTRAV]グハ、S.とP.フランシス、「キャラとNATのとファイアウォールによるTCPトラバーサルの測定」、インターネット測定コンファレンス（バークレー、CA）、2005年10月の議事。
Authors' Addresses
著者のアドレス
Saikat Guha (editor) Cornell University 331 Upson Hall Ithaca, NY 14853 US Phone: +1 607 255 1008 EMail: saikat@cs.cornell.edu
Saikatグハ（エディタ）コーネル大学331アップソンホールイサカ、NY 14853米国電話：+1 607 255 1008 Eメール：saikat@cs.cornell.edu
Kaushik Biswas Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 US Phone: +1 408 525 5134 EMail: kbiswas@cisco.com
Kaushikによるビスワスシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134米国電話：+1 408 525 5134 Eメール：kbiswas@cisco.com
Bryan Ford Max Planck Institute for Software Systems Campus Building E1 4 D-66123 Saarbruecken Germany Phone: +49-681-9325657 EMail: baford@mpi-sws.org
+ 49-681-9325657電子メール：：baford@mpi-sws.orgソフトウェアシステムズキャンパスビルE1 4 D-66123ザールブリュッケンドイツ電話のためのブライアン・フォードマックスプランク研究所
Senthil Sivakumar Cisco Systems, Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 US Phone: +1 919 392 5158 EMail: ssenthil@cisco.com
Senthilさんシバクマーシスコ・システムズ・インク7100から8キットクリーク道路私書箱14987リサーチトライアングルパーク、ノースカロライナ州27709から4987米国電話：+1 919 392 5158 Eメール：ssenthil@cisco.com
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 US Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com
Pyda Srisuresh Kazeon Systems、Inc.の1161年サンアントニオRdを。マウンテンビュー、カリフォルニア州94043米国電話：+1 408 836 4773 Eメール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。