[要約] RFC 5382は、TCPに対するNATの動作要件を定義したものであり、NATがTCP通信を適切に処理するためのガイドラインを提供しています。このRFCの目的は、TCP通信をNAT環境で正しく動作させるための基準を確立することです。
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
TCPのNAT行動要件
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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の要件を設定します。このドキュメントの目的は、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の側面は範囲外です。NATを直接制御するミドルボックス通信（MIDCOM）やユニバーサルプラグアンドプレイ（UPNP）など、NATトラバーサルへのシグナルベースのアプローチは範囲外です。最後に、NAT（たとえば、HTTPまたはSecure Shell Protocol（SSH）管理インターフェイス）とNATによって開始されたTCP接続（たとえば、信頼性の高い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]を参照できます。[beveave-udp]は、IPおよびUDPのコンテキストにおけるNATの用語と要件をレイアウトします。この文書は、TCPトラフィックを処理するNATの要件を設定することにより、これらを補完します。[beave-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]は、元の定義[RFC0793]から現在の実装へのTCPの進化を記録しています。混雑制御とフロー制御、セキュリティ、および高帯域幅ネットワークのサポートに関してTCPでは多くの変化がありますが、接続を開始するプロセス（つまり、3方向の握手または同時開いたもの）はほとんど変化していません。NATが最も影響を与えるのは、接続開始のプロセスです。T/TCP [RFC1644]などの実験的アプローチは、代替の接続開始アプローチを提案していますが、複雑でサービス拒否攻撃の影響を受けやすいことがわかりました。その結果、最新のオペレーティングシステムとNATは、[RFC0793]に記載されているように、主に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で機能させるために多くの手法が考案されています。[スタント]、[Natblaster]、および[P2PNAT]は、ピアツーピアアプリケーションがNATを介してTCPを確立できるようにする一方的な自己アドレス固定（UNSAF）メカニズムを説明しています。これらのアプローチでは、エンドポイントアプリケーションのみを変更し、標準に準拠した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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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」には、「Basic 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).
このドキュメントでは、「TCP接続」という用語（または「接続」）という用語を使用して、4タプル（ソースおよび宛先IPアドレスとTCPポート）と初期シーケンス番号（ISN）によって識別される個々の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].
このドキュメントでは、[beveave-udp]で定義されている「アドレスとポートマッピング」（または「マッピング」のみ）という用語を使用して、ネットワークアドレスとTCP接続のポート翻訳に必要なNATの状態を参照しています。このドキュメントでは、「エンドポイント非依存マッピング」、「アドレス依存マッピング」、「アドレスとポート依存マッピング」、「フィルタリング動作」、「エンドポイントに依存するフィルタリング」、「アドレス依存フィルタリング」、「アドレス依存フィルタリング」という用語も使用します。ポート依存フィルタリング、「ポート割り当て」、「ポートオーバーロード」、「ヘアピニング」、[Bevive-UDP]で定義されている「外部ソースIPアドレスとポート」。
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接続のパケットを翻訳します。マッピングは、内側から開始された接続に対して動的に割り当てられ、特定の後続の接続に対して再利用される可能性があります。[beveave-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'）します。その後まもなく、エンドポイントは同じ（x：x）から外部アドレス（y2：y2）への接続を開始し、NATでマッピング（x2 '：x2'）を取得します。[beave-udp]によると、（x1 '：x1'）が（x2 '：x2'）（y2：y2）のすべての値に等しい場合、NATは「エンドポイントに依存しないマッピング」動作を持つように定義されます。（x1 '：x1'）が（x2 '：x2'）y2がy1に等しい場合にのみ（x2 '：x2'）、NATは「アドレス依存マッピング」動作を持つように定義されます。（x1 '：x1'）が（x2 '：x2'）の場合にのみ（y2：y2）等しい場合（y1：y1）、最初に終了した直後に同じ外部アドレスへの連続した接続とNATがNATの場合にのみ可能ですtime_wait状態で接続の状態を保持し、NATは「アドレスとポート依存のマッピング」動作を持つように定義されます。このドキュメントでは、（x1 '：x1'）は（x2 '：x2'）、つまり、新しいマッピングが割り当てられることはありません。そのような場合、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が必要です。エンドポイントに依存しないマッピング動作により、ピアツーピアアプリケーションは、外部のピアがそれに連絡できるように内部エンドポイントに割り当てられた外部IPアドレスとポートを学習および宣伝することができます（NATのセキュリティポリシーの対象）。NATのセキュリティポリシーは、マッピング動作とは無関係であり、セクション4.3で後述します。エンドポイントに依存しないマッピング動作により、PEER-TO-PEERアプリケーションは、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、および接続用のその他のパケットを変換します。この接続開始方法は、3方向の握手（[RFC0793]で定義）に対応し、すべての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が受信されると確立されたと見なされます。NATの観点から見ると、内部ホストのsynパケットは、同じ接続のインバウンドsynパケットによって満たされます（3方向の握手中のsyn-ackパケットとは対照的に）。この交換に続いて、接続に対してアウトバウンドとインバウンド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]).
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ウェイハンドシェイクモードの処理に加えて、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パケットに加えて、同時開放をサポートするために、内部で開始された接続のインバウンドsynとアウトバウンドsyn-ackを受け入れるためにNATを準備する必要があります。
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'）を割り当て（または再利用する）内部IPアドレスとポート（x：x）の前と同じように考えてください。外部エンドポイント（Y2：Y2）は、（x1 '：x1'）にsynを送信することにより、内部エンドポイントとの接続を開始しようとします。NATは、接続の確立を許可するか、接続を許可するかを選択できます。NATが接続を許可することを選択した場合、インバウンドsynを翻訳し、既存のマッピングに従って（x：x）にルーティングします。また、（x：x）で生成されたsyn-ackを応答して翻訳し、（y2：y2）などにルーティングします。あるいは、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により、セキュリティポリシーが許可されている場合、既存のマッピングを外部から開始された接続によって再利用できる場合があります。[bevave-udp]で説明されているように、いくつかの異なるポリシーが可能です。NATがすべて（Y2：Y2）からの接続開始を許可する場合、「エンドポイントに依存しないフィルタリング」動作があると定義されます。NATがY2がY1に等しい場合にのみ接続開始を許可する場合、NATは「アドレス依存フィルタリング」動作を持つように定義されます。（y2：y2）が（y1：y1）等しい場合にのみNATが接続の開始を許可する場合、NATは「アドレスとポート依存のフィルタリング」動作を持つように定義されます（最初の接続が終了した直後に可能ですが、マッピングはマッピングですまだアクティブです）。このドキュメントで定義されている追加のフィルタリング動作の1つは、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の存在下で動作し続けることを許可することです。また、この動作により、動作補完NATの背後にあるアプリケーションが、非行動コンプライアント（レガシー）NATの背後にあるリモートエンドポイントと相互運用することができます。リモートエンドポイントのNATにエンドポイントに依存しないマッピング動作がなく、外部IPアドレスが1つしかない場合、ローカル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.
対応するマッピングが存在しないため、またはNATのフィルタリング挙動のために、インバウンドsynパケットがフィルタリングされている場合、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 Aidsを同時に開けるSyn Aidsを静かにドロップします。アプリケーションは同時オープンを試みており、内部エンドポイントからのアウトバウンドsynがまだNATを越えていないことを考えてください（2つのエンドポイント間のネットワーク輻輳または時計が歪んでいるため）。それ以外の場合、このアウトバウンドsynは、インバウンドsynの翻訳を可能にするためにNATで必要なマッピングを作成しました。アウトバウンドsynは時間内にNATに到達しなかったため、インバウンドsynを処理することはできません。NATが、外部エンドポイントに接続の試みを放棄するように強制するエラーメッセージを使用して早期のインバウンドSynに応答する場合、TCP同時オープンを実行するアプリケーションを妨げます。代わりに、NATがInbound 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サポートは、両方ともアプリケーションにとって重要です。残念ながら、NATがエンドポイントに同時オープンを中止することを強制せずにNATがエラーを通知する方法はありません。TCPRSTとICMPポートの到達不可能なパケットは、ICMPホストとネットワークの到達不可能なエラーが試みを中止するためにエンドポイントを中止する必要があります。同じホストまたはネットワークへのその他の接続[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).
さらに、NATが未承諾のSynを受信した場合、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パケットを静かにドロップする必要があります。それ以外の場合、NATは、REQ-4Aが適用されない限り、元のSynに対してICMPポートの到達不可能なエラー（タイプ3、コード3）を送信する必要があります。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がそのようなエラー通知をレートリミットまたは省略する理由がある場合があります。攻撃を下回ったときにSynパケットを静かにドロップすると、追加のネットワーク帯域幅を消費せず、攻撃者へのNATの存在を明らかにすることなく、同時に開放されます。セクション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は、SynsではなくNATのホストを意図したSynsにのみ適用されます。NAT自体を対象としています。インバウンドSynがNATのホストを対象としているかどうかを判断する1つの方法は、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接続と部分的に開いた接続が続くことです。NATは、TCP Keep-Aliveパケットを送信し、それに応じてTCP RSTパケットを受信することにより、セッションのエンドポイントがクラッシュしたかどうかを確認できます。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つのフェーズを通過します。部分的に開いた位相で、エンドポイントは初期シーケンス番号を同期します。位相は、接続の最初のSynによって開始され、両方のエンドポイントがACKフラグセット（TCP状態：Syn_SentおよびSyn_rcvd）でパケットを送信するまで拡張されます。両方向のACKは、アプリケーションデータを無期限に交換できる確立されたフェーズの始まりをマークします（TCP状態：確立、FIN_WAIT_1、FIN_WAIT_2、およびCLOSE_WAIT）。両方のエンドポイントがFINパケットを送信することにより、両方のエンドポイントが接続の半分を終了したときに終了フェーズが始まります。FINパケットが両方向に見られると、アプリケーションデータを交換できなくなりますが、スタックはまだFINパケットが受信されることを確認する必要があります（TCP状態：閉じることと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接続は、パケットを交換することなく、確立された位相を無期限に留まることができます。一部のエンドホストは、このようなアイドル接続にキープアライブパケットを送信するように構成できます。デフォルトでは、そのようなキープアライブパケットは、有効にすると2時間ごとに送信されます[RFC1122]。その結果、わずかに2時間以上待つNATは、デフォルトレートで送信されるキープアライブパケットでアイドル接続を検出できます。一方、部分的に開いたフェーズまたはクロージングフェーズでのTCP接続は、飛行中のパケットが配信されるのを待っている間、最大4分間アイドル状態を維持できます[RFC1122]。
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：TCP接続のエンドポイントがアクティブであるかどうかをNATが判断できない場合、しばらくの間アイドル状態であればセッションを放棄する可能性があります。そのような場合、「確立された接続のアイドルタイムアウト」の値は、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が接続が生存しているかどうかを積極的に判断できない場合、この要件により、アプリケーションはデフォルトレート（2時間ごと）でキープアライブパケットを送信できることを保証し、NATが接続が生きていることを受動的に判断できます。追加の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.
RSTパケットを処理するためのNATの動作、またはtime_wait状態の接続は不特定のままです。NATは、最後のACKの再送信に対応するために、time_wait状態の接続の状態を保持する場合があります。ただし、TIME_WAIT状態は一般にTCP接続を適切に閉じて内部エンドポイントで遭遇するため、閉じた接続の状態を保持すると、リソースが限られているNATを介した接続のスループットが制限される場合があります。[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.
アクティブマッピングがない接続用の非シンパケットの処理は、不特定のままになります。このようなパケットは、NATがライブ接続を静かに放棄した場合、または4分間のtime_wait期間が期限切れになる前に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.
最初の通知を送信すると、エンドポイントアプリケーションがより迅速に回復することができます。ただし、たとえば、停電のためにセッション状態が失われた場合、エンドポイントの通知が常に可能であるとは限りません。
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.
特定のNATのアプリケーションレベルゲートウェイ（ALG）は、アプリケーションプロトコル内に埋め込まれたIPアドレスとTCPポートを変更します。このようなアルグは、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（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.
正当化：この要件の意図は、ALGがUNSAFメソッドに干渉するのを防ぐことです。FTPアルグのデフォルトの状態は、レガシーの懸念のために不特定のままにされています。このメモを書いている時点で、レガシーFTPクライアントの大部分はパッシブ（PASV）モードを有効にし、NATを横断するためにアルグを必要とします。
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行動要件のリストは、[bevave-udp]で説明されています。ICMP固有のNAT行動要件のリストは、[beave-icmp]で説明されています。以下にリストされている要件は、TCPに直接影響するこれら2つのドキュメントからの要件を繰り返しています。次の要件では、[beave-udp]または[beave-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は、[beave-udp]で定義され、「ポートオーバーロード」の「ポート割り当て」動作を持つことができます。このような動作は、共通の外部エンドポイントへの同時接続を確立するのと同じマッピングを共有する2つの内部エンドポイントを防ぐため、望ましくありません。
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は特定の状況でアプリケーションのセキュリティを損なう可能性があります。IPアドレスとソースTCPポート範囲のセキュリティ（「R」コマンドなど）のみに依存するアプリケーションは、攻撃者と同じ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で、その内部アドレスに戻ることは、[Beave-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）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の背後にある2つのアプリケーションが許可されます。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 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メカニズムは、TCPセグメントの送信によってトリガーされるICMPエラーメッセージの受信に依存します。そのようなメカニズムの1つは、TCPの正しい動作に必要なPATH MTU発見[RFC1191]です。現在のPATH MTU発見メカニズムでは、TCPセグメントの送信者にICMP「データグラムが大きすぎる」応答を通知する必要があります。
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]）。さらに、TCPの接続の確立およびメンテナンスメカニズムは、ICMP宛先の到達不可能なメッセージが発信される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".
この仕様のすべての必須要件（つまり、「必須」）をサポートし、[beave-udp]に準拠しているNATは、「この仕様に準拠しています」。この仕様のすべての要件をサポートする（つまり、「推奨」を含む）、[beave-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ウェイハンドシェイクモードの処理に加えて、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パケットを静かにドロップする必要があります。それ以外の場合、NATは、REQ-4Aが適用されない限り、元のSynに対してICMPポートの到達不可能なエラー（タイプ3、コード3）を送信する必要があります。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：TCP接続のエンドポイントがアクティブであるかどうかをNATが判断できない場合、しばらくの間アイドル状態であればセッションを放棄する可能性があります。そのような場合、「確立された接続のアイドルタイムアウト」の値は、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（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に直接影響する[bevave-udp]または[bevave-icmp]からの要件を繰り返します。このドキュメントは、[beave-udp]または[beave-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）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.
[beave-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のセキュリティ上の考慮事項：NATが提供するセキュリティは、[beave-udp]で扱われているように、そのフィルタリング動作によって支配されます。接続依存のフィルタリング動作は、ファイアウォールの観点から最も安全ですが、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が未承諾のインバウンドSynパケットに応答し、ICMPエラーが数秒遅れたことが推奨されます。そうすることで、外部攻撃者に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.
Joe Touchは、未承諾のインバウンドSynを処理するメカニズムに貢献しました。マーク・オールマン、フランソワ・オーデット、ラース・エガート、ポール・フランシス、フェルナンド・ゴント、サム・ハートマン、ポール・ホフマン、デイブ・ハドソン、カレン・ジェニングス、フィリップ・マシューズ、トム・ペティス、マグナス・ウェスターランド、ダン・ウィングの多くの貢献、コメント、提案について。
[BEHAVE-UDP] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[beave-udp] audet、F。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、1985年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[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月。
[BEHAVE-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, June 2008.
[beave-icmp] Srisuresh、P.、Ford、B.、Sivakumar、S。、およびS. Guha、「ICMPプロトコルのNAT行動要件」、2008年6月の作業進行中。
[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.、Pai、N。、およびC. Wang、「ネットワークアドレス翻訳者の管理オブジェクトの定義（NAT）、RFC 4008、2005年3月。
[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.、Wilson、G。、およびA. Perrig、「Natblaster：Natsの背後にあるホスト間のTCP接続の確立」、ACM Sigcomm Asia Workshop（Beijing、China）の議事録、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] Ford、B.、Srisuresh、P。、およびD. Kegel、「ネットワークアドレス翻訳者全体のピアツーピア通信」、2005年4月、USENIX年次技術会議（Anaheim、CA）の議事録。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337] Braden、B。、「TCPにおける時間待ち暗殺の危険」、RFC 1337、1992年5月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644] Braden、B。、「T/TCP -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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ascondage Options」、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. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryの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] Duke、M.、Braden、R.、Eddy、W。、およびE. Blanton、「伝送制御プロトコル（TCP）仕様文書のロードマップ」、RFC 4614、2006年9月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953] Touch、J。、「スプーフィング攻撃に対するTCPの防御」、RFC 4953、2007年7月。
[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.
[スタント]グハ、S。およびP.フランシス、「ナッツ：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] Guha、S。およびP. Francis、「NATとファイアウォールを介したTCPトラバーサルの特性評価と測定」、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 Guha（編集者）Cornell University 331 Upson Hall Ithaca、NY 14853米国電話：1 607 255 1008メール：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 Biswas Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134米国電話：1 408 525 5134メール：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
Bryan Ford Max Planck Software Systems Institute for Software Systems Campus Building E1 4 D-66123 Saarbrueckenドイツ電話：49-681-9325657電子メール：baford@mpi-sws.org
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 Sivakumar Cisco Systems、Inc。7100-8 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709-4987米国電話：1 919 392 5158メール：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 San Antonio Rd。カリフォルニア州マウンテンビュー94043米国電話：1 408 836 4773メール：srisuresh@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。