Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6146 UC3M
Category: Standards Track P. Matthews
ISSN: 2070-1721 Alcatel-Lucent
I. van Beijnum
IMDEA Networks
April 2011
Stateful NAT64: Network Address and Protocol Translation
from IPv6 Clients to IPv4 Servers
Abstract
抽象
This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server.
この文書は、IPv6のみのクライアントは、ユニキャストUDP、TCP、またはICMPを使用したIPv4サーバーに接続することを可能にするステートフルNAT64変換を、説明しています。 NAT64の翻訳者に割り当てられた1つ以上のパブリックIPv4アドレスは、いくつかのIPv6のみのクライアント間で共有されています。ステートフルNAT64はDNS64と組み合わせて使用した場合、変更は通常のIPv6またはIPv4クライアントサーバーに必要ありません。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6146.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6146で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Features of Stateful NAT64 . . . . . . . . . . . . . . . . 5
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Stateful NAT64 Solution Elements . . . . . . . . . . . 6
1.2.2. Stateful NAT64 Behavior Walk-Through . . . . . . . . . 8
1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Stateful NAT64 Normative Specification . . . . . . . . . . . . 14
3.1. Binding Information Bases . . . . . . . . . . . . . . . . 14
3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Packet Processing Overview . . . . . . . . . . . . . . . . 17
3.4. Determining the Incoming Tuple . . . . . . . . . . . . . . 18
3.5. Filtering and Updating Binding and Session Information . . 20
3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . . 21
3.5.1.1. Rules for Allocation of IPv4 Transport
Addresses for UDP . . . . . . . . . . . . . . . . 23
3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . . 24
3.5.2.1. State Definition . . . . . . . . . . . . . . . . . 24
3.5.2.2. State Machine for TCP Processing in the NAT64 . . 25
3.5.2.3. Rules for Allocation of IPv4 Transport
Addresses for TCP . . . . . . . . . . . . . . . . 33
3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 33
3.5.4. Generation of the IPv6 Representations of IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . 36
3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . . 36
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and
for ICMP Error Messages Containing a TCP or UDP
Packets . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query
Messages and for ICMP Error Messages Containing an
ICMP Query . . . . . . . . . . . . . . . . . . . . . . 38
3.7. Translating the Packet . . . . . . . . . . . . . . . . . . 38
3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . . 39
4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5.1. Implications on End-to-End Security . . . . . . . . . . . 40
5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Attacks on NAT64 . . . . . . . . . . . . . . . . . . . . . 41
5.4. Avoiding Hairpinning Loops . . . . . . . . . . . . . . . . 42
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . . 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 44
This document specifies stateful NAT64, a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. Together with DNS64 [RFC6147], these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated when either end uses existing, NAT-traversal, peer-to-peer communication techniques, such as Interactive Connectivity Establishment (ICE) [RFC5245]. Stateful NAT64 also supports IPv4-initiated communications to a subset of the IPv6 hosts through statically configured bindings in the stateful NAT64.
この文書は、ステートフルNAT64はIPv4-IPv6への移行とIPv4-IPv6の共存のための機構を指定します。一緒にDNS64 [RFC6147]を用いて、これら2つのメカニズムがIPv6専用クライアントは、IPv4のみサーバへの通信を開始することを可能にします。彼らはまた、いずれかの端部は、既存の使用する場合に、通信を開始することができ、IPv4とIPv6ノード間のピア・ツー・ピア通信を可能にする、NATトラバーサル、そのようなインタラクティブ接続確立（ICE）などのピア・ツー・ピア通信技術、[ RFC5245]。ステートフルNAT64はまた、ステートフルNAT64に静的に設定されたバインディングを介してIPv6ホストのサブセットにIPv4に開始された通信をサポートします。
Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice versa. The translation is done by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC6145]. The IPv4 addresses of IPv4 hosts are algorithmically translated to and from IPv6 addresses by using the algorithm defined in [RFC6052] and an IPv6 prefix assigned to the stateful NAT64 for this specific purpose. The IPv6 addresses of IPv6 hosts are translated to and from IPv4 addresses by installing mappings in the normal Network Address Port Translation (NAPT) manner [RFC3022]. The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.
ステートフルNAT64は、IPv4パケット及びその逆にIPv6パケットを変換するための機構です。翻訳は、[RFC6145]で定義されたIP / ICMP翻訳アルゴリズムに従ってパケットのヘッダを変換することによって行われます。 IPv4ホストのIPv4アドレスは、アルゴリズム[RFC6052]で定義されたアルゴリズムと、この特定の目的のためにステートフルNAT64に割り当てられたIPv6プレフィックスを使用してIPv6アドレスへとから翻訳されます。 IPv6ホストのIPv6アドレスは、通常のネットワークアドレスポート変換（NAPT）方法[RFC3022]でマッピングをインストールすることにより、およびIPv4アドレスから翻訳されます。現在の仕様は、TCP、UDP、およびICMPトラフィックを運ぶユニキャストパケットを変換する方法ステートフルNAT64を定義します。ストリーム制御伝送プロトコル（SCTP）、データグラム輻輳制御プロトコル（DCCP）、およびIPsecを含むマルチキャストパケットと他のプロトコルは、本明細書の範囲外です。
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. The IPv6 address contained in the synthetic AAAA RR is algorithmically generated from the IPv4 address and the IPv6 prefix assigned to a NAT64 device by using the same algorithm defined in [RFC6052].
DNS64は、資源レコードからAAAAリソースレコード（RR）を合成するための機構です。合成AAAAのRRに含まれるIPv6アドレスはアルゴリズムIPv4アドレスと[RFC6052]で定義された同じアルゴリズムを使用して、NAT64デバイスに割り当てられたIPv6プレフィックスから生成されます。
Together, these two mechanisms allow an IPv6-only client (i.e., a host with a networking stack that only implements IPv6, a host with a networking stack that implements both protocols but with only IPv6 connectivity, or a host running an IPv6-only application) to initiate communications to an IPv4-only server (which is analogous to the IPv6-only host above).
一緒に、これら2つのメカニズムがIPv6のみ、両方のプロトコルを実装し、ネットワークスタックを持つだけでIPv6接続、またはIPv6のみのアプリケーションを実行しているホストのホストを実装し、ネットワークスタックとIPv6専用クライアント（すなわち、ホストを許可します））IPv6のみ上記ホストに類似している（IPv4専用サーバへの通信を開始します。
These mechanisms are expected to play a critical role in IPv4-IPv6 transition and IPv4-IPv6 coexistence. Due to IPv4 address depletion, it is likely that in the future, the new clients will be IPv6-only and they will want to connect to the existing IPv4-only servers. The stateful NAT64 and DNS64 mechanisms are easily deployable, since they do not require changes to either the IPv6 client or the IPv4 server.
これらのメカニズムは、IPv4にIPv6への移行とIPv4-IPv6の共存に重要な役割を果たすことが期待されています。 IPv4アドレス枯渇に、将来的には、新しいクライアントはIPv6のみとなり、彼らは既存のIPv4専用のサーバーに接続したいだろうと思われます。彼らはIPv6クライアントまたはIPv4サーバのいずれかに変更を必要としないので、ステートフルNAT64とDNS64のメカニズムは、簡単に展開可能です。
For basic functionality, the approach only requires the deployment of the stateful NAT64 function in the devices connecting an IPv6-only network to the IPv4-only network, along with the deployment of a few DNS64-enabled name servers accessible to the IPv6-only hosts. An analysis of the application scenarios can be found in [RFC6144].
基本的な機能のために、アプローチは、IPv6のみのホストにアクセス数DNS64対応のネームサーバの導入に伴い、IPv4のみのネットワークにIPv6のみのネットワークを接続するデバイスでのステートフルNAT64機能の導入が必要で。アプリケーションシナリオの分析は、[RFC6144]に見出すことができます。
For brevity, in the rest of the document, we will refer to the stateful NAT64 either as stateful NAT64 or simply as NAT64.
簡潔にするために、文書の残りの部分では、我々はステートフルNAT64として、あるいは単にNAT64としてのいずれかで、ステートフルNAT64を参照します。
The features of NAT64 are:
NAT64の機能は次のとおりです。
o NAT64 is compliant with the recommendations for how NATs should handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. As such, NAT64 only supports Endpoint-Independent Mappings and supports both Endpoint-Independent and Address-Dependent Filtering. Because of the compliance with the aforementioned requirements, NAT64 is compatible with current NAT traversal techniques, such as ICE [RFC5245], and with other NAT traversal techniques.
O NAT64は、NATのは、UDP [RFC4787]、TCP [RFC5382]、およびICMP [RFC5508]をどのように扱うかについての勧告に準拠しています。そのため、NAT64は、エンドポイントのみに依存しないマッピングをサポートし、エンドポイントに依存しないとアドレス依存フィルタリングの両方をサポートしています。なぜなら前述の要件の遵守、NAT64は、ICE [RFC5245]として現在のNATトラバーサル技法との互換性、および他のNATトラバーサル技法です。
o In the absence of preexisting state in a NAT64, only IPv6 nodes can initiate sessions to IPv4 nodes. This works for roughly the same class of applications that work through IPv4-to-IPv4 NATs.
O NAT64状態を既存の非存在下で、唯一のIPv6ノードは、IPv4ノードにセッションを開始することができます。これは、IPv4からIPv4 NATを介して動作するアプリケーションのほぼ同じクラスのために働きます。
o Depending on the filtering policy used (Endpoint-Independent, or Address-Dependent), IPv4-nodes might be able to initiate sessions to a given IPv6 node, if the NAT64 somehow has an appropriate mapping (i.e., state) for an IPv6 node, via one of the following mechanisms:
NAT64は何とかのIPv6ノードのための適切なマッピング（すなわち、状態）を有する場合に使用されるフィルタポリシー（エンドポイント非依存、またはアドレス依存性）に応じて、O、のIPv4ノードは、所与のIPv6ノードにセッションを開始することができるかもしれません、以下のメカニズムの1つを介して：
* The IPv6 node has recently initiated a session to the same or another IPv4 node. This is also the case if the IPv6 node has used a NAT-traversal technique (such as ICE).
* IPv6ノードは最近、同じまたは別のIPv4ノードへのセッションを開始しました。 IPv6ノードは、（例えば、ICEなど）NATトラバーサル技法を使用している場合にも同様です。
* A statically configured mapping exists for the IPv6 node.
*静的に構成されたマッピングは、IPv6ノードのために存在します。
o IPv4 address sharing: NAT64 allows multiple IPv6-only nodes to share an IPv4 address to access the IPv4 Internet. This helps with the forthcoming IPv4 exhaustion.
O IPv4アドレスを共有する：NAT64は、複数のIPv6専用ノードはIPv4インターネットにアクセスするためにIPv4アドレスを共有することを可能にします。これは、今後のIPv4枯渇に役立ちます。
o As currently defined in this NAT64 specification, only TCP, UDP, and ICMP are supported. Support for other protocols (such as other transport protocols and IPsec) is to be defined in separate documents.
Oなど現在このNAT64仕様で定義された、唯一のTCP、UDP、およびICMPがサポートされています。 （例えば、他のトランスポートプロトコルとIPsecのような）他のプロトコルのサポートは別の文書で定義されるべきです。
This section provides a non-normative introduction to NAT64. This is achieved by describing the NAT64 behavior involving a simple setup that involves a single NAT64 device, a single DNS64, and a simple network topology. The goal of this description is to provide the reader with a general view of NAT64. It is not the goal of this section to describe all possible configurations nor to provide a normative specification of the NAT64 behavior. So, for the sake of clarity, only TCP and UDP are described in this overview; the details of ICMP, fragmentation, and other aspects of translation are purposefully avoided in this overview. The normative specification of NAT64 is provided in Section 3.
このセクションでは、NAT64への非規範的な導入を提供します。これは、単一のNAT64デバイス、単一DNS64、および簡単なネットワークトポロジを伴う簡単なセットアップを含むNAT64の振る舞いを記述することによって達成されます。この説明の目的は、NAT64の概観を読者に提供することです。すべての可能な構成を説明するためにも、NAT64行動の規範的な仕様を提供するために、このセクションの目的ではありません。だから、明確化のために、唯一のTCPとUDPは、この概要で説明されています。 ICMP、断片化、および翻訳の他の態様の詳細は意図的にこの概要では回避されています。 NAT64の規範的仕様は、第3節で提供されます。
The NAT64 mechanism is implemented in a device that has (at least) two interfaces, an IPv4 interface connected to the IPv4 network, and an IPv6 interface connected to the IPv6 network. Packets generated in the IPv6 network for a receiver located in the IPv4 network will be routed within the IPv6 network towards the NAT64 device. The NAT64 will translate them and forward them as IPv4 packets through the IPv4 network to the IPv4 receiver. The reverse takes place for packets generated by hosts connected to the IPv4 network for an IPv6 receiver. NAT64, however, is not symmetric. In order to be able to perform IPv6-IPv4 translation, NAT64 requires state. The state contains the binding of an IPv6 address and TCP/UDP port (hereafter called an IPv6 transport address) to an IPv4 address and TCP/UDP port (hereafter called an IPv4 transport address).
NAT64機構は、（少なくとも）二つのインターフェース、IPv4ネットワークに接続されたIPv4インタフェースとIPv6ネットワークに接続されたIPv6インタフェースを有する装置に実装されています。 IPv4ネットワークに位置する受信機のIPv6ネットワークで生成されたパケットは、NAT64デバイスに向かってIPv6ネットワーク内でルーティングされます。 NAT64はそれらを翻訳し、IPv4の受信機にIPv4ネットワーク経由のIPv4パケットとしてそれらを転送します。逆は、IPv6受信機のためのIPv4ネットワークに接続されたホストによって生成されたパケットのために行われます。 NAT64は、しかし、対称ではありません。 IPv6にIPv4の変換を実行することができるようにするために、NAT64は、状態が必要です。状態は、IPv6アドレスとIPv4アドレスとTCP / UDPポートへのTCP / UDPポート（以下、IPv6トランスポートアドレスと呼ばれる）（以下、IPv4トランスポートアドレスと呼ばれる）の結合を含んでいます。
Such binding state is either statically configured in the NAT64 or it is created when the first packet flowing from the IPv6 network to the IPv4 network is translated. After the binding state has been created, packets flowing in both directions on that particular flow are translated. The result is that, in the general case, NAT64 only supports communications initiated by the IPv6-only node towards an IPv4-only node. Some additional mechanisms (like ICE) or static binding configuration can be used to provide support for communications initiated by an IPv4-only node to an IPv6-only node.
このような結合状態は、静的NAT64に構成されているか、IPv4ネットワークへのIPv6ネットワークから流れる第1のパケットが翻訳されるときに作成されます。結合状態が作成された後、その特定のフロー上の両方向に流れるパケットが翻訳されます。結果は、一般的な場合において、NAT64のみIPv4専用ノードに向かってIPv6専用ノードによって開始された通信をサポートすることです。いくつかの追加の機構（ICEなど）または静的な結合構成がIPv6専用ノードとIPv4専用ノードによって開始される通信のためのサポートを提供するために使用することができます。
In this section, we describe the different elements involved in the NAT64 approach.
このセクションでは、NAT64のアプローチに関連するさまざまな要素について説明します。
The main component of the proposed solution is the translator itself. The translator has essentially two main parts, the address translation mechanism and the protocol translation mechanism.
提案された解決策の主な成分は、翻訳者自身です。翻訳者は、基本的に2つの主要部分、アドレス変換メカニズムとプロトコル変換機構を備えています。
Protocol translation from an IPv4 packet header to an IPv6 packet header and vice versa is performed according to the IP/ICMP Translation Algorithm [RFC6145].
IPv6パケットヘッダーおよびその逆にIPv4パケットヘッダからプロトコル変換は、IP / ICMP翻訳アルゴリズム[RFC6145]に従って実行されます。
Address translation maps IPv6 transport addresses to IPv4 transport addresses and vice versa. In order to create these mappings, the NAT64 has two pools of addresses: an IPv6 address pool (to represent IPv4 addresses in the IPv6 network) and an IPv4 address pool (to represent IPv6 addresses in the IPv4 network).
アドレス変換は、IPv4トランスポートアドレスとその逆にIPv6トランスポートアドレスをマッピングします。 IPv6アドレスプール（IPv6ネットワークでIPv4アドレスを表すように）とIPv4アドレスプール（IPv4ネットワークでIPv6アドレスを表すように）これらのマッピングを作成するために、NAT64は、アドレスの二つのプールを有しています。
The IPv6 address pool is one or more IPv6 prefixes assigned to the translator itself. Hereafter, we will call the IPv6 address pool Pref64::/n; in the case there is more than one prefix assigned to the NAT64, the comments made about Pref64::/n apply to each of them. Pref64::/n will be used by the NAT64 to construct IPv4-Converted IPv6 addresses as defined in [RFC6052]. Due to the abundance of IPv6 address space, it is possible to assign one or more Pref64::/n, each of them being equal to or even bigger than the size of the whole IPv4 address space. This allows each IPv4 address to be mapped into a different IPv6 address by simply concatenating a Pref64::/n with the IPv4 address being mapped and a suffix. The provisioning of the Pref64::/n as well as the address format are defined in [RFC6052].
IPv6アドレスプールは、翻訳者自身に割り当てられた1つまたは複数のIPv6プレフィックスです。以降では、IPv6アドレスのプールPref64 :: / Nを呼び出します。場合にNAT64に割り当てられた複数のプレフィックス、Pref64についてのコメントはあり:: / nは、それらのそれぞれに適用されます。 Pref64は:: / N [RFC6052]で定義されたIPv4変換IPv6アドレスを構成するためにNAT64によって使用されるであろう。 IPv6アドレス空間の豊かさのために、一つ以上のPref64 :: / Nを割り当て、それらのそれぞれに等しいか、全IPv4アドレス空間のサイズよりもさらに大きなことが可能です。これは、各IPv4アドレスは単に:: / NマッピングされるIPv4アドレスと接尾辞Pref64を連結することによって、異なるIPv6アドレスにマッピングされることを可能にします。 Pref64 :: / Nならびにアドレス形式のプロビジョニングは、[RFC6052]で定義されています。
The IPv4 address pool is a set of IPv4 addresses, normally a prefix assigned by the local administrator. Since IPv4 address space is a scarce resource, the IPv4 address pool is small and typically not sufficient to establish permanent one-to-one mappings with IPv6 addresses. So, except for the static/manually created ones, mappings using the IPv4 address pool will be created and released dynamically. Moreover, because of the IPv4 address scarcity, the usual practice for NAT64 is likely to be the binding of IPv6 transport addresses into IPv4 transport addresses, instead of IPv6 addresses into IPv4 addresses directly, enabling a higher utilization of the limited IPv4 address pool. This implies that NAT64 performs both address and port translation.
IPv4アドレスプールは、IPv4アドレスのセット、ローカル管理者によって割り当てられ、通常の接頭辞です。 IPv4アドレス空間は希少資源であるので、IPv4アドレスプールは小さく、IPv6アドレスを持つ永久的な1対1マッピングを確立するために一般的に十分ではありません。だから、静的/手動で作成したものを除き、IPv4アドレスプールを使用してマッピングが作成され、動的にリリースしました。また、理由はIPv4アドレス不足を、NAT64のための通常の練習は、IPv4は、限られたIPv4アドレスプールのより高い利用を可能にする、直接アドレスにIPv6アドレスの代わりに、IPv4トランスポートアドレスへのIPv6トランスポート・アドレスの結合である可能性が高いです。これは、NAT64は、アドレスとポート変換の両方を実行することを意味します。
Because of the dynamic nature of the IPv6-to-IPv4 address mapping and the static nature of the IPv4-to-IPv6 address mapping, it is far simpler to allow communications initiated from the IPv6 side toward an IPv4 node, whose address is algorithmically mapped into an IPv6 address, than communications initiated from IPv4-only nodes to an IPv6 node. In that case, an IPv4 address needs to be associated with the IPv6 node's address dynamically.
ためのIPv6からIPv4アドレスマッピングとIPv4からIPv6アドレスマッピングの静的な性質の動的な性質のため、そのアドレスアルゴリズムマッピングされ、IPv4ノードに向けたIPv6側から開始された通信を可能にするために、はるかに簡単ですIPv6アドレスに、IPv6ノードにIPv4専用ノードから開始された通信に比べ。その場合には、IPv4アドレスを動的IPv6ノードのアドレスと関連していることが必要です。
Using a mechanism such as DNS64, an IPv6 client obtains an IPv6 address that embeds the IPv4 address of the IPv4 server and sends a packet to that IPv6 address. The packets are intercepted by the NAT64 device, which associates an IPv4 transport address out of its
このようDNS64のようなメカニズムを使用して、IPv6クライアントは、IPv4サーバのIPv4アドレスを埋め込み、そのIPv6アドレスにパケットを送信したIPv6アドレスを取得します。パケットのうちIPv4トランスポートアドレスを関連付けるNAT64デバイスによってインターセプトされ、その
IPv4 pool to the IPv6 transport address of the initiator, creating binding state, so that reply packets can be translated and forwarded back to the initiator. The binding state is kept while packets are flowing. Once the flow stops, and based on a timer, the IPv4 transport address is returned to the IPv4 address pool so that it can be reused for other communications.
イニシエータのIPv6トランスポートアドレスへのIPv4プール、応答パケットを変換し、バックイニシエータに転送することができるように、結合状態を作り出します。パケットが流れている間、結合状態が保たれています。流れが停止したら、それは他の通信のために再利用できるように、タイマーに基づいて、IPv4トランスポートアドレスは、IPv4アドレスプールに戻されます。
To allow an IPv6 initiator to do a DNS lookup to learn the address of the responder, DNS64 [RFC6147] is used to synthesize AAAA RRs from the A RRs. The IPv6 addresses contained in the synthetic AAAA RRs contain a Pref64::/n assigned to the NAT64 and the IPv4 address of the responder. The synthetic AAAA RRs are passed back to the IPv6 initiator, which will initiate an IPv6 communication with an IPv6 address associated to the IPv4 receiver. The packet will be routed to the NAT64 device, which will create the IPv6-to-IPv4 address mapping as described before.
IPv6のイニシエータは、レスポンダのアドレスを学習するDNSルックアップを行うことができるようにするには、DNS64 [RFC6147]はAのRRからAAAA RRを合成するために使用されます。合成AAAA資源レコードに含まれるIPv6アドレスはPref64 :: / N NAT64とレスポンダのIPv4アドレスに割り当てられているが含まれています。合成AAAA RRはバックIPv4の受信機に関連したIPv6アドレスとIPv6通信を開始するのIPv6イニシエータに渡されます。パケットは、前述のようにのIPv6からIPv4アドレスマッピングを作成するNAT64デバイスにルーティングされます。
In this section, we provide a simple example of the NAT64 behavior. We consider an IPv6 node that is located in an IPv6-only site and that initiates a TCP connection to an IPv4-only node located in the IPv4 network.
このセクションでは、NAT64の挙動の簡単な例を提供します。私たちは、IPv6のみのサイトにあるIPv6ノードを考えると、それはIPv4ネットワークにあるIPv4のみのノードへのTCP接続を開始します。
The scenario for this case is depicted in the following figure:
この場合のシナリオを次の図に描かれています。
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | network |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +-------+ | 192.0.2.1 |
|2001:db8::1|------| NAT64 |----| |
| | +-------+ | |
| | | | |
+---------------------+ +---------------+
The figure above shows an IPv6 node H1 with an IPv6 address 2001:db8::1 and an IPv4 node H2 with IPv4 address 192.0.2.1. H2 has h2.example.com as its Fully Qualified Domain Name (FQDN).
DB8 :: 1及びIPv4アドレス192.0.2.1とIPv4ノードのH2：上図は、IPv6アドレス2001とIPv6ノードのH1を示しています。 H2は、その完全修飾ドメイン名（FQDN）としてh2.example.comています。
A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 uses the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent IPv4 addresses in the IPv6 address space and a single IPv4 address 203.0.113.1 assigned to its IPv4 interface. The routing is configured in such a way that the IPv6 packets addressed to a destination address in 64:ff9b::/96 are routed to the IPv6 interface of the NAT64 device.
NAT64は、IPv4ネットワークにIPv6ネットワークとを接続します。このNAT64は、周知のプレフィックス64を使用する：ff9b :: IPv6アドレス空間とそのIPv4インタフェースに割り当てられた単一のIPv4アドレス203.0.113.1でIPv4アドレスを表すために[RFC6052]で定義された/ 96。 ff9b :: / 96は、NAT64装置のIPv6インタフェースにルーティングされる：ルーティングは、IPv6パケット64の宛先アドレスにアドレス指定するように構成されています。
Also shown is a local name server with DNS64 functionality. The local name server uses the Well-Known Prefix 64:ff9b::/96 to create the IPv6 addresses in the synthetic RRs.
また、DNS64機能を備えたローカルネームサーバが示されています。合成のRRにIPv6アドレスを作成するためにff9b :: / 96：ローカルネームサーバは、よく知られているプレフィックス64を使用しています。
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and the local name server does the recursive lookups.
この例では、IPv6ホストのみスタブリゾルバを持つ典型的なDNSの状況を想定し、ローカルネームサーバは再帰的な検索を行います。
The steps by which H1 establishes communication with H2 are:
H1はH2との通信を確立することにより、手順は次のとおりです。
1. H1 performs a DNS query for h2.example.com and receives the synthetic AAAA RR from the local name server that implements the DNS64 functionality. The AAAA record contains an IPv6 address formed by the Well-Known Prefix and the IPv4 address of H2 (i.e., 64:ff9b::192.0.2.1).
1. H1はh2.example.comのDNSクエリを実行し、DNS64の機能を実装するローカルネームサーバから合成AAAA RRを受信します。 AAAAレコードは、周知のプレフィックスとH2のIPv4アドレスによって形成されたIPv6アドレスが含まれている（すなわち、64：ff9b :: 192.0.2.1）。
2. H1 sends a TCP SYN packet to H2. The packet is sent from a source transport address of (2001:db8::1,1500) to a destination transport address of (64:ff9b::192.0.2.1,80), where the ports are set by H1.
2. H1はH2にTCP SYNパケットを送信します。 （：ff9b :: 192.0.2.1,80 64）、ポートはH1によって設定された先のトランスポートアドレスに：（DB8 :: 1,1500 2001）パケットの送信元トランスポート・アドレスから送信されます。
3. The packet is routed to the IPv6 interface of the NAT64 (since IPv6 routing is configured that way).
3.パケットはNAT64のIPv6インタフェースにルーティングされる（IPv6ルーティングので、そのように構成されています）。
* The NAT64 selects an unused port (e.g., 2000) on its IPv4
address 203.0.113.1 and creates the mapping entry
(2001:db8::1,1500) <--> (203.0.113.1,2000)
* The NAT64 translates the IPv6 header into an IPv4 header using the IP/ICMP Translation Algorithm [RFC6145].
* NAT64はIP / ICMP翻訳アルゴリズム[RFC6145]を使用して、IPv4ヘッダにIPv6ヘッダを変換します。
* The NAT64 includes (203.0.113.1,2000) as the source transport address in the packet and (192.0.2.1,80) as the destination transport address in the packet. Note that 192.0.2.1 is extracted directly from the destination IPv6 address of the received IPv6 packet that is being translated. The destination port 80 of the translated packet is the same as the destination port of the received IPv6 packet.
* NAT64は、パケットの宛先トランスポートアドレスとして（203.0.113.1,2000）ソーストランスポートパケットのアドレスおよび（192.0.2.1,80）として含みます。 192.0.2.1が翻訳されて受信されたIPv6パケットの宛先IPv6アドレスから直接抽出されることに留意されたいです。翻訳されたパケットの宛先ポート80は、受信したIPv6パケットの宛先ポートと同じです。
5. The NAT64 sends the translated packet out of its IPv4 interface and the packet arrives at H2.
5. NAT64は、そのIPv4インタフェースの外に翻訳されたパケットを送信し、パケットがH2に到着します。
6. H2 node responds by sending a TCP SYN+ACK packet with the destination transport address (203.0.113.1,2000) and source transport address (192.0.2.1,80).
6. H2ノードは、宛先トランスポートアドレス（203.0.113.1,2000）とソーストランスポートアドレス（192.0.2.1,80）とTCP SYN + ACKパケットを送信することによって応答します。
7. Since the IPv4 address 203.0.113.1 is assigned to the IPv4 interface of the NAT64 device, the packet is routed to the NAT64 device, which will look for an existing mapping containing (203.0.113.1,2000). Since the mapping (2001:db8::1,1500) <--> (203.0.113.1,2000) exists, the NAT64 performs the following operations:
7. IPv4アドレス203.0.113.1をNAT64デバイスのIPv4インタフェースに割り当てられているので、パケットを含む既存のマッピング（203.0.113.1,2000）を探しますNAT64デバイスにルーティングされます。マッピング（2001：DB8 :: 1,1500）ので< - >（203.0.113.1,2000）が存在する、NAT64は、次の操作を実行します。
* The NAT64 translates the IPv4 header into an IPv6 header using
the IP/ICMP Translation Algorithm [RFC6145].
* The NAT64 includes (2001:db8::1,1500) as the destination transport address in the packet and (64:ff9b::192.0.2.1,80) as the source transport address in the packet. Note that 192.0.2.1 is extracted directly from the source IPv4 address of the received IPv4 packet that is being translated. The source port 80 of the translated packet is the same as the source port of the received IPv4 packet.
* NAT64は（2001：DB8 :: 1,1500）を含むパケットの宛先トランスポートアドレスとAS：パケットの送信元トランスポートアドレスとして（64 ff9b :: 192.0.2.1,80）。 192.0.2.1が翻訳されて、受信したIPv4パケットの送信元IPv4アドレスから直接抽出されることに留意されたいです。翻訳されたパケットの送信元ポート80は、受信したIPv4パケットの送信元ポートと同じです。
The packet exchange between H1 and H2 continues, and packets are translated in the different directions as previously described.
H1とH2の間でパケット交換が継続し、前述のようにパケットは異なる方向に翻訳されます。
It is important to note that the translation still works if the IPv6 initiator H1 learns the IPv6 representation of H2's IPv4 address (i.e., 64:ff9b::192.0.2.1) through some scheme other than a DNS lookup. This is because the DNS64 processing does NOT result in any state being installed in the NAT64 and because the mapping of the IPv4 address into an IPv6 address is the result of concatenating the Well-Known Prefix to the original IPv4 address.
DNSルックアップ以外のいくつかの方式を通じて：（ff9b :: 192.0.2.1すなわち、64）IPv6のイニシエータH1はH2のIPv4アドレスのIPv6の表現を学習した場合、翻訳がまだ動作していることに注意することが重要です。 DNS64処理はNAT64およびIPv6アドレスにIPv4アドレスのマッピングは、元IPv4アドレスに周知のプレフィックスを連結した結果であるため、インストールされている任意の状態をもたらさないからです。
NAT64 may do filtering, which means that it only allows a packet in through an interface under certain circumstances. The NAT64 can filter IPv6 packets based on the administrative rules to create entries in the binding and session tables. The filtering can be flexible and general, but the idea of the filtering is to provide the administrators necessary control to avoid denial-of-service (DoS) attacks that would result in exhaustion of the NAT64's IPv4 address, port, memory, and CPU resources. Filtering techniques of incoming IPv6 packets are not specific to the NAT64 and therefore are not described in this specification.
NAT64は、それだけで、特定の状況下で、インタフェースを介してパケットを許可することを意味するフィルタリングを行うことができます。 NAT64は結合し、セッションテーブルにエントリを作成するには、管理者ルールに基づいて、IPv6パケットをフィルタリングすることができます。フィルタリングは、柔軟かつ一般的なことができますが、フィルタリングのアイデアは、NAT64のIPv4アドレス、ポート、メモリ、およびCPU資源の枯渇につながるサービス拒否（DoS）攻撃を避けるために、管理者に必要な制御を提供することです。着信IPv6パケットのフィルタリング技術は、NAT64に固有ではないため、この明細書に記載されていません。
Filtering of IPv4 packets, on the other hand, is tightly coupled to the NAT64 state and therefore is described in this specification. In this document, we consider that the NAT64 may do no filtering, or it may filter incoming IPv4 packets.
IPv4パケットのフィルタリングは、一方で、しっかりNAT64状態に結合され、したがって、本明細書に記載されています。この文書では、我々は、NAT64は何のフィルタリングを行わないこと、またはそれが入ってくるIPv4パケットをフィルタリングすることができることを考えます。
NAT64 filtering of incoming IPv4 packets is consistent with the recommendations of [RFC4787] and [RFC5382]. Because of that, the NAT64 as specified in this document supports both Endpoint-Independent Filtering and Address-Dependent Filtering, both for TCP and UDP as well as filtering of ICMP packets.
着信IPv4パケットのNAT64フィルタリングは[RFC4787]及び[RFC5382]の推奨と一致しています。そのため、この文書で指定されたNAT64は、両方のTCPおよびUDPだけでなく、ICMPパケットのフィルタリングに、エンドポイントに依存しないフィルタリングとアドレス依存フィルタリングの両方をサポートしています。
If a NAT64 performs Endpoint-Independent Filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped unless the NAT64 has state for the destination transport address of the incoming IPv4 packet.
NAT64が着信IPv4パケットのエンドポイント非依存フィルタリングを行う場合NAT64着信IPv4パケットの宛先トランスポートアドレスの状態を持っていない限り、着信IPv4パケットはドロップされます。
If a NAT64 performs Address-Dependent Filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped unless the NAT64 has state involving the destination transport address of the IPv4 incoming packet and the particular source IP address of the incoming IPv4 packet.
NAT64が着信IPv4パケットのアドレス依存フィルタリングを行う場合NAT64がIPv4着信パケットと着信IPv4パケットの特定の送信元IPアドレスの宛先トランスポートアドレスを含む状態を有している場合を除き、着信IPv4パケットはドロップされます。
This section provides a definitive reference for all the terms used in this document.
このセクションでは、この文書で使用されるすべての用語のための決定的なリファレンスを提供します。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The following additional terms are used in this document:
次の追加条項がこの文書で使用されています。
3-Tuple: The tuple (source IP address, destination IP address, ICMP Identifier). A 3-tuple uniquely identifies an ICMP Query session. When an ICMP Query session flows through a NAT64, each session has two different 3-tuples: one with IPv4 addresses and one with IPv6 addresses.
3タプル：タプル（送信元IPアドレス、宛先IPアドレス、ICMP識別子）。 3タプルは一意ICMPクエリーセッションを識別する。 IPv4アドレスを有するものとIPv6アドレスとのいずれかICMPクエリーセッションはNAT64流れると、各セッションは、二つの異なる3タプルを有します。
5-Tuple: The tuple (source IP address, source port, destination IP address, destination port, transport protocol). A 5-tuple uniquely identifies a UDP/TCP session. When a UDP/TCP session flows through a NAT64, each session has two different 5-tuples: one with IPv4 addresses and one with IPv6 addresses.
5タプル：タプル（送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、トランスポートプロトコル）。 5タプルは一意UDP / TCPセッションを識別する。 IPv4アドレスを有するものとIPv6アドレスとのいずれかUDP / TCPセッションがNAT64流れると、各セッションは、二つの異なる5タプルを有します。
BIB: Binding Information Base. A table of bindings kept by a NAT64. Each NAT64 has a BIB for each translated protocol. An implementation compliant to this document would have a BIB for TCP, one for UDP, and one for ICMP Queries. Additional BIBs would be added to support other protocols, such as SCTP.
BIB：情報ベースを結合。 NAT64によって保持バインディングのテーブル。各NAT64は、各翻訳プロトコルのBIBを有しています。この文書に準拠した実装は、TCPのためのBIB、UDPのための1、およびICMPクエリのための1つを持っているでしょう。追加のビブは、SCTPなどの他のプロトコルをサポートするために追加されます。
Endpoint-Independent Mapping: In NAT64, using the same mapping for all the sessions involving a given IPv6 transport address of an IPv6 host (irrespectively of the transport address of the IPv4 host involved in the communication). Endpoint-Independent Mapping is important for peer-to-peer communication. See [RFC4787] for the definition of the different types of mappings in IPv4-to-IPv4 NATs.
エンドポイント非依存マッピング：NAT64において、IPv6ホストの指定されたIPv6トランスポートアドレス（無関係の通信に関与するIPv4ホストのトランスポートアドレス）を含むすべてのセッションのために同じマッピングを使用。エンドポイントに依存しないマッピングは、ピア・ツー・ピア通信のために重要です。 IPv4のツーのIPv4 NATの内のマッピングの異なるタイプの定義については、[RFC4787]を参照してください。
Filtering, Endpoint-Independent: The NAT64 only filters incoming IPv4 packets destined to a transport address for which there is no state in the NAT64, regardless of the source IPv4 transport address. The NAT forwards any packets destined to any transport address for which it has state. In other words, having state for a given transport address is sufficient to allow any packets back to the internal endpoint. See [RFC4787] for the definition of the different types of filtering in IPv4-to-IPv4 NATs.
フィルタリング、エンドポイント非依存：NAT64のみに関係なくソースIPv4トランスポートアドレスを、NAT64には状態がないいるトランスポート・アドレス宛ての着信IPv4パケットをフィルタリングします。 NATは、それが状態を持っている任意のトランスポート・アドレス宛てのすべてのパケットを転送します。換言すれば、所定のトランスポートアドレスの状態を有するバック内部エンドポイントへの任意のパケットを許可するのに十分です。 IPv4の対のIPv4のNATにおけるフィルタリングの異なるタイプの定義については[RFC4787]を参照。
Filtering, Address-Dependent: The NAT64 filters incoming IPv4 packets destined to a transport address for which there is no state (similar to the Endpoint-Independent Filtering). Additionally, the NAT64 will filter out incoming IPv4 packets coming from a given IPv4 address X and destined for a transport address for which it has state if the NAT64 has not sent packets to X previously (independently of the port used by X). In other words, for receiving packets from a specific IPv4 endpoint, it is necessary for the IPv6 endpoint to send packets first to that specific IPv4 endpoint's IP address.
フィルタリング、アドレス依存：NAT64は、（エンドポイント非依存フィルタリングに類似）は状態がないいるトランスポート・アドレス宛ての着信IPv4パケットをフィルタリングします。また、NAT64は、与えられたIPv4アドレスXからの着信IPv4パケットをフィルタリングし、NAT64は（独立Xによって使用されるポートの）以前にXにパケットを送信していない場合、それは状態を持っているトランスポート・アドレス宛てであろう。 IPv6のエンドポイントは、最初にその特定のIPv4エンドポイントのIPアドレスにパケットを送信するために他の言葉では、特定のIPv4エンドポイントからパケットを受信するために、それが必要です。
Hairpinning: Having a packet do a "U-turn" inside a NAT and come back out the same side as it arrived on. If the destination IPv6 address and its embedded IPv4 address are both assigned to the NAT64 itself, then the packet is being sent to another IPv6 host connected to the same NAT64. Such a packet is called a 'hairpin packet'. A NAT64 that forwards hairpin packets back to the IPv6 host is defined as supporting "hairpinning". Hairpinning support is important for peer-to-peer applications, as there are cases when two different hosts on the same side of a NAT can only communicate using sessions that hairpin through the NAT. Hairpin packets can be either TCP or UDP. More detailed explanation of hairpinning and examples for the UDP case can be found in [RFC4787].
ヘアピニング：NATの内側に「Uターン」を行うと、それが到着したのと同じ側から戻ってくるパケットを持ちます。宛先IPv6アドレスとその埋め込みIPv4アドレスの両方NAT64自身に割り当てられている場合、パケットは同一のNAT64に接続された他のIPv6ホストに送信されます。このようなパケットを「ヘアピンパケット」と呼ばれます。バックIPv6ホストにヘアピンパケットを転送NAT64は「ヘアピン」をサポートするものとして定義されます。 NATの同じ側の2つの異なるホストのみNATを介してヘアピンセッションを使用して通信することができる場合があるような支持体をヘアピニングは、ピア・ツー・ピア・アプリケーションのために重要です。ヘアピンパケットがTCPまたはUDPのいずれかになります。ヘアピンとUDPの場合の例のより詳細な説明は、[RFC4787]に見出すことができます。
ICMP Query packet: ICMP packets that are not ICMP error messages. For ICMPv6, ICMPv6 Query Messages are the ICMPv6 Informational messages as defined in [RFC4443]. For ICMPv4, ICMPv4 Query messages are all ICMPv4 messages that are not ICMPv4 error messages.
ICMPクエリパケット：ICMPエラーメッセージではありませんICMPパケット。 [RFC4443]で定義されるようにICMPv6のために、ICMPv6のクエリメッセージのICMPv6情報メッセージです。 ICMPv4のために、ICMPv4のクエリメッセージはICMPv4のエラーメッセージではありませんすべてのICMPv4メッセージです。
Mapping or Binding: A mapping between an IPv6 transport address and a IPv4 transport address or a mapping between an (IPv6 address, ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) pair. Used to translate the addresses and ports / ICMP Identifiers of packets flowing between the IPv6 host and the IPv4 host. In NAT64, the IPv4 address and port / ICMPv4 Identifier is always one assigned to the NAT64 itself, while the IPv6 address and port / ICMPv6 Identifier belongs to some IPv6 host.
マッピングまたは結合：IPv6トランスポートアドレスとIPv4トランスポートアドレス又は間のマッピング（IPv6アドレス、ICMPv6の識別子）ペアとの間のマッピング（IPv4アドレス、ICMPv4の識別子）ペア。アドレスとポートを変換するために使用/ IPv6ホストとIPv4ホスト間を流れるパケットのICMP識別子。 IPv6アドレスとポート/ ICMPv6の識別子は、いくつかのIPv6ホストに属しながらNAT64、IPv4アドレス及びポートに/ ICMPv4の識別子は、常にNAT64自体に割り当てられたものです。
Session: The flow of packets between two different hosts. This may be TCP, UDP, or ICMP Queries. In NAT64, typically one host is an IPv4 host, and the other one is an IPv6 host. However, due to hairpinning, both hosts might be IPv6 hosts.
セッション：二つの異なるホスト間のパケットの流れ。これは、TCP、UDP、またはICMPクエリであってもよいです。 NAT64では、典型的には1つのホストがIPv4ホストであり、他方がIPv6ホストです。しかし、ヘアピンのために、両方のホストでは、IPv6ホストであるかもしれません。
Session table: A table of sessions kept by a NAT64. Each NAT64 has three session tables, one for TCP, one for UDP, and one for ICMP Queries.
セッションテーブル：NAT64によって保たれたセッションのテーブル。各NAT64は3つのセッションテーブル、TCPのための1つ、UDPのための1、およびICMPクエリのための1つを持っています。
Stateful NAT64: A function that has per-flow state that translates IPv6 packets to IPv4 packets and vice versa, for TCP, UDP, and ICMP. The NAT64 uses binding state to perform the translation between IPv6 and IPv4 addresses. In this document, we also refer to stateful NAT64 simply as NAT64.
ステートフルNAT64：TCP、UDP、およびICMPのために、IPv4パケット及びその逆にIPv6パケットを変換するフロー毎の状態を有する機能。 NAT64は、IPv6とIPv4アドレスの間の変換を実行するために結合状態を使用しています。この文書では、我々はまた、単にNAT64などのステートフルNAT64を参照してください。
Stateful NAT64 device: The device where the NAT64 function is executed. In this document, we also refer to stateful NAT64 device simply as NAT64 device.
ステートフルNAT64装置：NAT64機能を実行するデバイス。この文書では、我々はまた、単にNAT64デバイスとしてステートフルNAT64デバイスを参照してください。
Transport Address: The combination of an IPv6 or IPv4 address and a port. Typically written as (IP address,port), e.g., (192.0.2.15,8001).
トランスポートアドレス：IPv4またはIPv6アドレスとポートの組み合わせ。典型的には、例えば、（IPアドレス、ポート）、（192.0.2.15,8001）のように書きます。
Tuple: Refers to either a 3-tuple or a 5-tuple as defined above.
タプルは：上で定義した3タプルまたは5タプルのいずれかを指します。
For a detailed understanding of this document, the reader should also be familiar with NAT terminology [RFC4787].
この文書の詳細な理解のために、読者はまた、NAT用語[RFC4787]に精通しなければなりません。
A NAT64 is a device with at least one IPv6 interface and at least one IPv4 interface. Each NAT64 device MUST have at least one unicast /n IPv6 prefix assigned to it, denoted Pref64::/n. Additional considerations about the Pref64::/n are presented in Section 3.5.4. A NAT64 MUST have one or more unicast IPv4 addresses assigned to it.
NAT64は、少なくとも1つのIPv6インタフェースと、少なくとも1つのIPv4インタフェースを有する装置です。各NAT64デバイスがそれに割り当てられた少なくとも1つのユニキャスト/ N IPv6プレフィックスを持たなければならない、Pref64 :: / Nで示さ。 Pref64 :: / nは約その他の考慮事項は、3.5.4項に示されています。 NAT64は、それに割り当てられた1つ以上のユニキャストIPv4アドレスを持たなければなりません。
A NAT64 uses the following conceptual dynamic data structures:
NAT64は、次の概念的な動的なデータ構造を使用します。
o UDP Binding Information Base
O UDPは、情報ベースのバインディング
o UDP Session Table
O UDPセッションテーブル
o TCP Binding Information Base
O TCPは、情報ベースのバインディング
o TCP Session Table
O TCPセッション表
o ICMP Query Binding Information Base
O ICMPクエリは、情報ベースのバインディング
o ICMP Query Session Table
O ICMPクエリセッション表
These tables contain information needed for the NAT64 processing. The actual division of the information into six tables is done in order to ease the description of the NAT64 behavior. NAT64 implementations are free to use different data structures but they MUST store all the required information, and the externally visible outcome MUST be the same as the one described in this document.
これらのテーブルは、NAT64の処理に必要な情報が含まれています。 6つのテーブルへの情報の実際の分割は、NAT64の動作の説明を容易にするために行われます。 NAT64実装は異なるデータ構造を使用することは自由であるが、それらはすべての必要な情報を格納する必要があり、かつ外部から見える結果は、この文書に記載されたものと同じでなければなりません。
The notation used is the following: uppercase letters are IPv4 addresses; uppercase letters with a prime(') are IPv6 addresses; lowercase letters are ports; IPv6 prefixes of length n are indicated by "P::/n"; mappings are indicated as "(X,x) <--> (Y',y)".
使用される表記法は以下の通りである：大文字は、IPv4アドレスです。プライム（ '）との大文字は、IPv6アドレスです。小文字はポートです。長さnのIPv6プレフィックスは「P :: / N」によって示されています。 " - （Y」、Y）<>（X、X）" マッピングは、以下のように示されています。
A NAT64 has three Binding Information Bases (BIBs): one for TCP, one for UDP, and one for ICMP Queries. In the case of UDP and TCP BIBs, each BIB entry specifies a mapping between an IPv6 transport address and an IPv4 transport address:
TCPのための1つ、UDPのための1、およびICMP問合せの1：NAT64は3つのバインディング情報ベース（ビブ）を持っています。 UDPおよびTCPよだれ掛けの場合には、各BIBエントリは、IPv6トランスポートアドレスとIPv4トランスポート・アドレスの間のマッピングを指定します。
(X',x) <--> (T,t)
（X」、X）< - >（T、T）
where X' is some IPv6 address, T is an IPv4 address, and x and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64. The BIB has then two columns: the BIB IPv6 transport address and the BIB IPv4 transport address. A given IPv6 or IPv4 transport address can appear in at most one entry in a BIB: for example, (2001:db8::17, 49832) can appear in at most one TCP and at most one UDP BIB entry. TCP and UDP have separate BIBs because the port number space for TCP and UDP are distinct. If the BIBs are implemented as specified in this document, it results in Endpoint-Independent Mappings in the NAT64. The information in the BIBs is also used to implement Endpoint-Independent Filtering. (Address-Dependent Filtering is implemented using the session tables described below.)
X「は、いくつかのIPv6アドレスである場合、Tは、IPv4アドレスであり、xおよびtはポートです。 Tは常にNAT64に割り当てられたIPv4アドレスのいずれかになります。 BIB IPv6トランスポートアドレスとBIB IPv4トランスポートアドレス：BIBは、2つの列があります。与えられたIPv6またはIPv4トランスポートアドレスはBIBで最大1つのエントリに表示されることがあります。たとえば、（2001：DB8 :: 17、49832）は高々1つのTCPで最も1つのUDP BIBエントリで表示されます。 TCPやUDPのポート番号空間が異なっているため、TCPとUDPは、別々のビブを持っています。この文書で指定されているようビブが実装されている場合は、NAT64におけるエンドポイント非依存のマッピングになります。ビブの情報は、エンドポイント非依存フィルタリングを実装するために使用されます。 （アドレス依存フィルタリングは、後述するセッションテーブルを使用して実装されています。）
In the case of the ICMP Query BIB, each ICMP Query BIB entry specifies a mapping between an (IPv6 address, ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) pair.
ICMPクエリBIBの場合には、各ICMPクエリBIBエントリが（IPv6アドレス、ICMPv6の識別子）対（IPv4アドレス、ICMPv4の識別子）ペアの間のマッピングを指定します。
(X',i1) <--> (T,i2)
（X」、I1）< - >（T、I2）
where X' is some IPv6 address, T is an IPv4 address, i1 is an ICMPv6 Identifier, and i2 is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64. A given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can appear in at most one entry in the ICMP Query BIB.
X「は、いくつかのIPv6アドレスである場合、Tは、IPv4アドレスであり、I1はICMPv6の識別子であり、I2はICMPv4の識別子です。 Tは常にNAT64に割り当てられたIPv4アドレスのいずれかになります。 （IPv6のまたはIPv4アドレス、ICMPv6の又はICMPv4の識別子）所与の対は、ICMPクエリBIBで高々一つのエントリに表示されることができます。
Entries in any of the three BIBs can be created dynamically as the result of the flow of packets as described in Section 3.5, but they can also be created manually by an administrator. NAT64 implementations SHOULD support manually configured BIB entries for any of the three BIBs. Dynamically created entries are deleted from the corresponding BIB when the last session associated with the BIB entry is removed from the session table. Manually configured BIB entries are not deleted when there is no corresponding Session Table Entry and can only be deleted by the administrator.
セクション3.5で説明したように、3つのよだれ掛けの任意のエントリは、パケットの流れの結果として動的に作成することができるが、それらはまた、管理者が手動で作成することができます。 NAT64実装は、三のよだれ掛けのいずれかのために手動で設定BIBエントリをサポートしなければなりません。 BIBエントリに関連付けられている最後のセッションはセッションテーブルから削除されたときに動的に作成されたエントリは、対応するBIBから削除されます。手動で構成されたBIBエントリには、対応するセッションテーブルエントリが存在しないときに削除されず、管理者のみが削除できます。
A NAT64 also has three session tables: one for TCP sessions, one for UDP sessions, and one for ICMP Query sessions. Each entry keeps information on the state of the corresponding session. In the TCP and UDP session tables, each entry specifies a mapping between a pair of IPv6 transport addresses and a pair of IPv4 transport addresses:
TCPセッションの1、UDPセッションの1、およびICMPクエリセッションの1：NAT64も3つのセッションテーブルを持っています。各エントリには、対応するセッションの状態に関する情報を保持します。 TCPとUDPのセッションテーブルでは、各エントリは、IPv6トランスポート・アドレスのペアとIPv4トランスポート・アドレスのペア間のマッピングを指定します。
(X',x),(Y',y) <--> (T,t),(Z,z)
（X 'X）、（Y'、Y）< - >（T、T）、（Z、Z）
where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and x, y, z, and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64. Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained from Z using the algorithm applied by the NAT64 to create IPv6 representations of IPv4 addresses. y will always be equal to z.
X 'およびY' は、IPv6のアドレスである場合、TおよびZは、IPv4アドレスであり、X、Y、Z、tはポートです。 Tは常にNAT64に割り当てられたIPv4アドレスのいずれかになります。 Y「は常にIPv4アドレスZのIPv6の表現であるので、Y」は、IPv4アドレスのIPv6の表現を作成するために、NAT64によって適用されたアルゴリズムを用いてZから得られます。 yは常にZに等しくなります。
For each TCP or UDP Session Table Entry (STE), there are then five columns. The terminology used for the STE columns is from the perspective of an incoming IPv6 packet being translated into an outgoing IPv4 packet. The columns are:
各TCPやUDPセッションテーブルエントリ（STE）のために、5つの列が続いあります。 STE列に使用される用語は、発信IPv4パケットに翻訳され、着信IPv6パケットの観点からのものです。列は以下のとおりです。
The STE source IPv6 transport address; (X',x) in the example above.
STEソースIPv6トランスポートアドレス。 （X」、x）は、上記の例です。
The STE destination IPv6 transport address; (Y',y) in the example above.
STE先IPv6トランスポートアドレス。上記の例では（Y」、Y）。
The STE source IPv4 transport address; (T,t) in the example above.
STE元IPv4トランスポートアドレス。上記の例では（T、T）。
The STE destination IPv4 transport address; (Z,z) in the example above.
STE先のIPv4トランスポート・アドレス。上記の例では（Z、Z）。
The STE lifetime.
STE寿命。
In the ICMP Query session table, each entry specifies a mapping between a 3-tuple of IPv6 source address, IPv6 destination address, and ICMPv6 Identifier and a 3-tuple of IPv4 source address, IPv4 destination address, and ICMPv4 Identifier:
ICMPクエリーセッションテーブルにおいて、各エントリは、IPv6ソースアドレス、IPv6宛先アドレス、およびICMPv6の識別子とIPv4ソースアドレス、IPv4宛先アドレス、およびICMPv4の識別子の3組の3組との間のマッピングを指定します。
(X',Y',i1) <--> (T,Z,i2)
（X 'Y'、I1）< - >（T、Z、I2）
where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, i1 is an ICMPv6 Identifier, and i2 is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64. Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained from Z using the algorithm applied by the NAT64 to create IPv6 representations of IPv4 addresses.
X「およびY」は、IPv6のアドレスである場合、TおよびZは、IPv4アドレスであり、I1はICMPv6の識別子であり、I2はICMPv4の識別子です。 Tは常にNAT64に割り当てられたIPv4アドレスのいずれかになります。 Y「は常にIPv4アドレスZのIPv6の表現であるので、Y」は、IPv4アドレスのIPv6の表現を作成するために、NAT64によって適用されたアルゴリズムを用いてZから得られます。
For each ICMP Query Session Table Entry (STE), there are then seven columns:
各ICMPクエリセッションテーブルエントリ（STE）のために、7つの列は、あります。
The STE source IPv6 address; X' in the example above.
STE元IPv6アドレス。上記の例ではX」。
The STE destination IPv6 address; Y' in the example above.
STEの宛先IPv6アドレス。上記の例ではY」。
The STE ICMPv6 Identifier; i1 in the example above.
STE ICMPv6の識別子。上記の例では、I1。
The STE source IPv4 address; T in the example above.
STE元IPv4アドレス。上記の例では、T。
The STE destination IPv4 address; Z in the example above.
STE先IPv4アドレス。上記の例ではZ。
The STE ICMPv4 Identifier; i2 in the example above.
STE ICMPv4の識別子。上記の例では、I2。
The STE lifetime.
STE寿命。
The NAT64 uses the session state information to determine when the session is completed, and also uses session information for Address-Dependent Filtering. A session can be uniquely identified by either an incoming tuple or an outgoing tuple.
NAT64は、セッションが終了したときを決定するセッション状態情報を使用し、また、アドレス依存フィルタリングのためのセッション情報を使用しています。セッションが一意の着信タプルまたは発信タプルのいずれかによって同定することができます。
For each TCP or UDP session, there is a corresponding BIB entry, uniquely specified by either the source IPv6 transport address (in the IPv6 --> IPv4 direction) or the destination IPv4 transport address (in the IPv4 --> IPv6 direction). For each ICMP Query session, there is a corresponding BIB entry, uniquely specified by either the source IPv6 address and ICMPv6 Identifier (in the IPv6 --> IPv4 direction) or the destination IPv4 address and the ICMPv4 Identifier (in the IPv4 --> IPv6 direction). However, for all the BIBs, a single BIB entry can have multiple corresponding sessions. When the last corresponding session is deleted, if the BIB entry was dynamically created, the BIB entry is deleted.
（ - >のIPv6方向IPv4の） - （>のIPv4方向IPv6における）または宛先IPv4トランスポートアドレス各TCPまたはUDPセッションのために、対応するBIBエントリは一意のソースIPv6トランスポートアドレスのいずれかによって指定された、があります。 （ - >のIPv4方向IPv6における）または宛先IPv4アドレスとICMPv4の識別子（IPv4の - >各ICMPクエリーセッションのために、対応するBIBエントリは一意のソースIPv6アドレスとICMPv6の識別子のいずれかによって指定された、ありますIPv6の方向）。しかし、すべてのよだれかけのために、単一BIBエントリは、複数の対応するセッションを持つことができます。最後に対応するセッションが削除されるとBIBエントリが動的に作成された場合、BIBエントリが削除されます。
The NAT64 will receive packets through its interfaces. These packets can be either IPv6 packets or IPv4 packets, and they may carry TCP traffic, UDP traffic, or ICMP traffic. The processing of the packets will be described next. In the case that the processing is common to all the aforementioned types of packets, we will refer to the packet as the incoming IP packet in general. In the case that the processing is specific to IPv6 packets, we will explicitly refer to the incoming packet as an incoming IPv6 packet; analogous terminology will apply in the case of processing that is specific to IPv4 packets.
NAT64は、そのインタフェースを介してパケットを受信します。これらのパケットは、IPv6パケットまたはIPv4パケットのいずれかになります、そして、彼らはTCPトラフィック、UDPトラフィック、またはICMPトラフィックを運ぶことができます。パケットの処理について説明します。処理は、パケットのすべての前述のタイプに共通である場合には、我々は、一般的には、着信IPパケットとしてパケットを参照します。処理は、IPv6パケットに特異的である場合には、我々は、明示的着信IPv6パケットとして受信パケットを参照します。類似の用語は、IPv4パケットに固有の処理の場合に適用されます。
The processing of an incoming IP packet takes the following steps:
着信IPパケットの処理は、次の手順を実行します。
The details of these steps are specified in the following subsections.
これらのステップの詳細は以下のサブセクションで指定されています。
This breakdown of the NAT64 behavior into processing steps is done for ease of presentation. A NAT64 MAY perform the steps in a different order or MAY perform different steps, but the externally visible outcome MUST be the same as the one described in this document.
処理ステップへのNAT64の挙動のこの内訳は、プレゼンテーションを容易にするために行われます。 NAT64は異なる順序でステップを実行し得るか、または別のステップを実行してもよいが、外部から見える結果は、本書で説明したものと同じでなければなりません。
This step associates an incoming tuple with every incoming IP packet for use in subsequent steps. In the case of TCP, UDP, and ICMP error packets, the tuple is a 5-tuple consisting of the source IP address, source port, destination IP address, destination port, and transport protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting of the source IP address, destination IP address, and ICMP Identifier.
このステップは、その後の工程で使用するすべての着信IPパケットの着信タプルを関連付けます。 TCP、UDP、およびICMPエラーパケットの場合、タプルは、送信元IPアドレス、送信元ポート、宛先IPアドレス、宛先ポート、およびトランスポートプロトコルからなる5タプルです。 ICMPクエリの場合、タプルは、送信元IPアドレス、宛先IPアドレス、およびICMP識別子からなる3タプルです。
If the incoming IP packet contains a complete (un-fragmented) UDP or TCP protocol packet, then the 5-tuple is computed by extracting the appropriate fields from the received packet.
着信IPパケットは、完全な（非断片化）UDPまたはTCPプロトコルのパケットが含まれている場合、5タプルは、受信したパケットから適切なフィールドを抽出することによって計算されます。
If the incoming packet is a complete (un-fragmented) ICMP Query message (i.e., an ICMPv4 Query message or an ICMPv6 Informational message), the 3-tuple is the source IP address, the destination IP address, and the ICMP Identifier.
着信パケットが（非断片化）完全ICMP Queryメッセージ（すなわち、ICMPv4のクエリメッセージまたはICMPv6の情報メッセージ）である場合、3タプルは、送信元IPアドレス、宛先IPアドレス、およびICMP識別子です。
If the incoming IP packet contains a complete (un-fragmented) ICMP error message containing a UDP or a TCP packet, then the incoming 5-tuple is computed by extracting the appropriate fields from the IP packet embedded inside the ICMP error message. However, the role of source and destination is swapped when doing this: the embedded source IP address becomes the destination IP address in the incoming 5-tuple, the embedded source port becomes the destination port in the incoming 5-tuple, etc. If it is not possible to determine the incoming 5-tuple (perhaps because not enough of the embedded packet is reproduced inside the ICMP message), then the incoming IP packet MUST be silently discarded.
着信IPパケットがUDPまたはTCPパケットを含む完全な（非断片化）ICMPエラーメッセージが含まれている場合、着信5タプルは、ICMPエラーメッセージ内に埋め込まれたIPパケットから適切なフィールドを抽出することによって計算されます。これを行う際ただし、送信元と送信先の役割がスワップされます。埋め込まれた送信元IPアドレスが着信5タプル内の宛先IPアドレスになり、埋め込まれた送信元ポート等、着信5タプル内の宛先ポートになっている場合（おそらく埋め込まれたパケットの十分ではないが、ICMPメッセージの内部に再生されるため）、着信5タプル、着信IPパケットは黙って破棄しなければなりませんを決定することは不可能です。
If the incoming IP packet contains a complete (un-fragmented) ICMP error message containing an ICMP error message, then the packet is silently discarded.
着信IPパケットは、ICMPエラーメッセージを含む完全な（非断片化）ICMPエラーメッセージが含まれている場合、パケットは、黙って破棄されます。
If the incoming IP packet contains a complete (un-fragmented) ICMP error message containing an ICMP Query message, then the incoming 3-tuple is computed by extracting the appropriate fields from the IP packet embedded inside the ICMP error message. However, the role of source and destination is swapped when doing this: the embedded source IP address becomes the destination IP address in the incoming 3-tuple, the embedded destination IP address becomes the source address in the incoming 3-tuple, and the embedded ICMP Identifier is used as the ICMP Identifier of the incoming 3-tuple. If it is not possible to determine the incoming 3-tuple (perhaps because not enough of the embedded packet is reproduced inside the ICMP message), then the incoming IP packet MUST be silently discarded.
着信IPパケットはICMPクエリメッセージを含む完全な（非断片化）ICMPエラーメッセージが含まれている場合、着信3タプルは、ICMPエラーメッセージ内に埋め込まれたIPパケットから適切なフィールドを抽出することによって計算されます。しかし、送信元と宛先の役割はこれをやったときにスワップされる：埋め込まれたソースIPアドレスが入ってくる3組の宛先IPアドレスになり、埋め込まれた宛先IPアドレスが入ってくる3組のソースアドレスとなり、および組み込みICMP識別子、着信3タプルのICMP識別子として使用されます。それは（おそらく埋め込まれたパケットの十分でないため、ICMPメッセージの内部に再生される）着信3タプルを決定することができない場合は、着信IPパケットは、黙って破棄しなければなりません。
If the incoming IP packet contains a fragment, then more processing may be needed. This specification leaves open the exact details of how a NAT64 handles incoming IP packets containing fragments, and simply requires that the external behavior of the NAT64 be compliant with the following conditions:
着信IPパケットがフラグメントが含まれている場合は、より多くの処理が必要になることがあります。この仕様は、NAT64は断片を含む、着信IPパケットを処理し、単にNAT64の外部動作は、以下の条件に準拠することを要求する方法の正確な詳細を開く葉：
The NAT64 MUST handle fragments. In particular, NAT64 MUST handle fragments arriving out of order, conditional on the following:
NAT64は、フラグメントを処理する必要があります。特に、NAT64は、順不同で到着したフラグメントを処理する必要があり、以下の条件：
* The NAT64 MUST limit the amount of resources devoted to the storage of fragmented packets in order to protect from DoS attacks.
* NAT64は、DoS攻撃から保護するために断片化されたパケットの保存に捧げられたリソースの量を制限しなければなりません。
* As long as the NAT64 has available resources, the NAT64 MUST allow the fragments to arrive over a time interval. The time interval SHOULD be configurable and the default value MUST be of at least FRAGMENT_MIN.
*限りNAT64は、利用可能なリソースを持っているとして、NAT64は、フラグメントは、時間間隔で到着することを可能にしなければなりません。時間間隔は設定可能でなければならず、デフォルト値は、少なくともFRAGMENT_MINでなければなりません。
* The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero.
* NAT64は、UDP、TCPまたはICMPヘッダが完全にゼロに等しいオフセット断片を含有する断片内に含まれることを要求することができます。
For incoming packets carrying TCP or UDP fragments with a non-zero checksum, NAT64 MAY elect to queue the fragments as they arrive and translate all fragments at the same time. In this case, the incoming tuple is determined as documented above to the un-fragmented packets. Alternatively, a NAT64 MAY translate the fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the latter case, subsequent fragments may arrive before the first, and the rules (in the bulleted list above) about how the NAT64 handles (out-of-order) fragments apply.
非ゼロのチェックサムとTCPやUDPの断片を運ぶ着信パケットについて、NAT64は、彼らが到着したフラグメントをキューに選ぶことができると同時に、すべてのフラグメントを翻訳します。非断片化パケットに上記に記載されているように、この場合に、着信タプルが決定されます。彼らはそれが最初以外のフラグメントの5タプルを計算することを可能にする情報を格納することにより、到着あるいは、NAT64はフラグメントを変換してもよいです。後者の場合には、後続のフラグメントが最初の前に到着することができ、NAT64ハンドル（アウトオブオーダー）フラグメントは適用方法について（上記の箇条書きリスト内の）規則。
For incoming IPv4 packets carrying UDP packets with a zero checksum, if the NAT64 has enough resources, the NAT64 MUST reassemble the packets and MUST calculate the checksum. If the NAT64 does not have enough resources, then it MUST silently discard the packets. The handling of fragmented and un-fragmented UDP packets with a zero checksum as specified above deviates from that specified in [RFC6145].
NAT64は、十分なリソースを持っている場合、ゼロチェックサムとUDPパケットを運ぶの着信IPv4パケットの場合は、NAT64は、パケットを再構成しなければならなくて、チェックサムを計算しなければなりません。 NAT64は、十分なリソースを持っていない場合、それは静かにパケットを捨てなければなりません。上記指定されたチェックサムがゼロで断片化と非断片化されたUDPパケットの処理は[RFC6145]で指定されたものからずれています。
Implementers of NAT64 should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Implementers should also be aware of additional issues with reassembling packets at high rates, described in [RFC4963].
NAT64の実装者は、IPフラグメンテーションに対するよく知られた攻撃の数があることに注意する必要があります。 [RFC1858]と[RFC3128]を参照してください。実装者はまた、[RFC4963]で説明した高レートでパケットを再構築すると、追加の問題点、注意する必要があります。
If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP, or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 4 (Port Unreachable) to the source address of the received packet. NOTE: This behavior may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64.
着信パケットがTCP、UDP、または最後に次のヘッダ内のICMPv6以外のプロトコルが含まれているIPv6パケットの場合、パケットが破棄されるべきであると、セキュリティポリシー許せば、NAT64は、ICMPv6の宛先到達不能エラーメッセージを送信する必要がありますコード4（ポート到達不能）と、受信したパケットの送信元アドレスへ。注：この動作は、このようなSCTPやDCCPなどの他のプロトコルは、NAT64によって処理方法を定義し、将来の文書によって更新されてもよいです。
If the incoming packet is an IPv4 packet that contains a protocol other than TCP, UDP, or ICMPv4, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv4 Destination Unreachable error message with Code 2 (Protocol Unreachable) to the source address of the received packet. NOTE: This behavior may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64.
着信パケットがTCP、UDP、またはICMPv4の以外のプロトコルが含まれているIPv4パケットである場合、パケットが破棄されるべきであると、セキュリティポリシー許せば、NAT64は、コード2とICMPv4の宛先到達不能エラーメッセージを送信する必要があります（プロトコル受信したパケットの送信元アドレスに到達不能）。注：この動作は、このようなSCTPやDCCPなどの他のプロトコルは、NAT64によって処理方法を定義し、将来の文書によって更新されてもよいです。
This step updates binding and session information stored in the appropriate tables. This step may also filter incoming packets, if desired.
適切なテーブルに格納され、この結合工程の更新とセッション情報。所望であれば、このステップはまた、着信パケットをフィルタリングすることができます。
The details of this step depend on the protocol, i.e., UDP, TCP, or ICMP. The behaviors for UDP, TCP, and ICMP Queries are described in Section 3.5.1, Section 3.5.2, and Section 3.5.3, respectively. For the case of ICMP error messages, they do not affect in any way either the BIBs or the session tables, so there is no processing resulting from these messages in this section. ICMP error message processing continues in Section 3.6.
このステップの詳細は、プロトコル、すなわち、UDP、TCPまたはICMPに依存します。 UDP、TCP、およびICMPクエリのための行動は、それぞれ、3.5.1、3.5.2、および3.5.3項で説明されています。 ICMPエラーメッセージの場合のために、彼らはどのような方法ビブまたはセッションテーブルのいずれかに影響を与えませんので、このセクションでは、これらのメッセージの結果何も処理はありません。 ICMPエラーメッセージの処理は、セクション3.6で継続します。
Irrespective of the transport protocol used, the NAT64 MUST silently discard all incoming IPv6 packets containing a source address that contains the Pref64::/n. This is required in order to prevent hairpinning loops as described in Section 5. In addition, the NAT64 MUST only process incoming IPv6 packets that contain a destination address that contains Pref64::/n. Likewise, the NAT64 MUST only process incoming IPv4 packets that contain a destination address that belongs to the IPv4 pool assigned to the NAT64.
かかわらず、使用されるトランスポートプロトコルの、NAT64は静かPref64 :: / Nが含まれている送信元アドレスを含むすべての着信IPv6パケットを捨てなければなりません。これはまた、セクション5に記載されているようにヘアピニングループを防止するために必要とされる、NAT64のみPref64 :: / Nが含まれている宛先アドレスを含む着信IPv6パケットを処理しなければなりません。同様に、NAT64は、NAT64に割り当てられたIPv4プールに属している宛先アドレスを含む着信IPv4パケットを処理しなければなりません。
The following state information is stored for a UDP session:
次の状態情報は、UDPセッションのために保存されます。
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
結合：（X 'X）、（Y'、Y）< - >（T、T）、（Z、Z）
Lifetime: a timer that tracks the remaining lifetime of the UDP session. When the timer expires, the UDP session is deleted. If all the UDP sessions corresponding to a dynamically created UDP BIB entry are deleted, then the UDP BIB entry is also deleted.
生涯：UDPセッションの残りの寿命を追跡するタイマー。タイマーが満了すると、UDPセッションが削除されます。動的に作成されたUDP BIBエントリに対応するすべてのUDPセッションが削除された場合は、UDP BIBエントリも削除されます。
An IPv6 incoming packet with an incoming tuple with source transport address (X',x) and destination transport address (Y',y) is processed as follows:
次のようにソース転送アドレス（X「X）と宛先トランスポートアドレス（Y」、Y）の着信タプルとIPv6の着信パケットが処理されます。
The NAT64 searches for a UDP BIB entry that contains the BIB IPv6 transport address that matches the IPv6 source transport address (X',x). If such an entry does not exist, the NAT64 tries to create a new entry (if resources and policy permit). The source IPv6 transport address of the packet (X',x) is used as the BIB IPv6 transport address, and the BIB IPv4 transport address is set to (T,t), which is allocated using the rules defined in Section 3.5.1.1. The result is a BIB entry as follows: (X',x) <--> (T,t).
NAT64は、IPv6送信元トランスポートアドレス（X」、X）と一致BIB IPv6トランスポートアドレスが含まれているUDP BIBエントリを検索します。そのようなエントリが存在しない場合は、NAT64は新しいエントリを作成しよう（リソースおよびポリシーを許可する場合）。パケットの送信元IPv6トランスポートアドレス（X」、X）は、BIB IPv6トランスポートアドレスとして使用され、そしてBIB IPv4トランスポートアドレス（T、t）に設定されている、セクション3.5.1.1で定義されたルールを使用して割り当てられています。次のように結果は、BIBのエントリである：（X」、X）< - >（T、T）。
The NAT64 searches for the Session Table Entry corresponding to the incoming 5-tuple. If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit). The information included in the session table is as follows:
NAT64は、着信5タプルに対応するセッションテーブルエントリを検索します。そのようなエントリが見つからない場合、NAT64は新しいエントリを作成しよう（リソースおよびポリシーを許可する場合）。次のようにセッションテーブルに含まれる情報は以下のとおりです。
* The STE source IPv6 transport address is set to (X',x), i.e., the source IPv6 transport address contained in the received IPv6 packet.
* STE元IPv6トランスポートアドレスに設定する（X」、X）、すなわち、受信したIPv6パケットに含まれる送信元IPv6トランスポートアドレス。
* The STE destination IPv6 transport address is set to (Y',y), i.e., the destination IPv6 transport address contained in the received IPv6 packet.
* STE宛先IPv6トランスポートアドレスは、すなわち（Y」、Y）、受信したIPv6パケットに含まれる宛先IPv6トランスポートアドレスに設定されています。
* The STE source IPv4 transport address is extracted from the corresponding UDP BIB entry, i.e., it is set to (T,t).
* STE元IPv4トランスポートアドレスは、すなわち、それが（T、t）に設定され、対応するUDP BIBエントリから抽出されます。
* The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e., Y') using the reverse algorithm (see Section 3.5.4).
* STE先IPv4トランスポート「は、（）、Y yはSTE宛先IPv6トランスポートアドレス及びZ（Yと同じポートであるZ（Y）」に設定）アルゴリズム（すなわち、Y」IPv6宛先アドレスから生成されています逆アルゴリズムを使用して）（）セクション3.5.4を参照してください。
The result is a Session Table Entry as follows: (X',x),(Y',y) <--> (T,t),(Z(Y'),y)
次のように結果がセッションテーブルエントリである：（X 'X）、（Y'、Y）< - >（T、t）は、（Z（Y '）、Y）
The NAT64 sets (or resets) the timer in the Session Table Entry to the maximum session lifetime. The maximum session lifetime MAY be configurable, and the default SHOULD be at least UDP_DEFAULT. The maximum session lifetime MUST NOT be less than UDP_MIN. The packet is translated and forwarded as described in the following sections.
NAT64セット（またはリセット）最大セッション存続時間にセッションテーブルエントリのタイマ。最大セッション存続期間は設定可能であり、デフォルトでは、少なくともUDP_DEFAULTであるべきです。最大セッション寿命はUDP_MIN以上でなければなりません。次のセクションで説明したように、パケットは、翻訳され転送されます。
An IPv4 incoming packet, with an incoming tuple with source IPv4 transport address (W,w) and destination IPv4 transport address (T,t) is processed as follows:
次のようにソースIPv4トランスポートアドレス（W、W）と宛先IPv4トランスポートアドレス（T、T）の着信タプルとIPv4の着信パケットは、処理されます。
The NAT64 searches for a UDP BIB entry that contains the BIB IPv4 transport address matching (T,t), i.e., the IPv4 destination transport address in the incoming IPv4 packet. If such an entry does not exist, the packet MUST be dropped. An ICMP error message with Type 3 (Destination Unreachable) MAY be sent to the original sender of the packet.
NAT64は、BIBのIPv4トランスポートアドレスマッチング（T、T）、即ち、着信IPv4パケットにIPv4の宛先トランスポートアドレスを含むUDP BIBエントリを検索します。そのようなエントリが存在しない場合、パケットは廃棄されなければなりません。タイプ3（宛先到達不能）とICMPエラーメッセージは、パケットの元の送信者に送ってもよいです。
If the NAT64 applies Address-Dependent Filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the Address-Dependent Filtering rule. To do this, it searches for a Session Table Entry with an STE source IPv4 transport address equal to (T,t), i.e., the destination IPv4 transport address in the incoming packet, and STE destination IPv4 address equal to W, i.e., the source IPv4 address in the incoming packet. If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, then an ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited).
NAT64は、そのIPv4インタフェース上のアドレス依存フィルタを適用した場合、NAT64は、着信パケットは、アドレス依存フィルタリング規則に従って許可されているかどうかをチェック。これを行うために、それは、すなわち、（T、t）に等しいSTE元IPv4トランスポートアドレスを持つセッションテーブルエントリ、すなわち、着信パケットの宛先IPv4トランスポートアドレス、およびWに等しいSTE先IPv4アドレスを検索します着信パケットの送信元IPv4アドレス。そのようなエントリが見つかった場合（複数あってもよい）、パケット処理が継続されます。そうでない場合、パケットは破棄されます。パケットが破棄された場合は、ICMPエラーメッセージは、パケットの元の送信者に送ってもよいです。 ICMPエラーメッセージは、送信された場合、3（宛先到達不能）とコード13（通信管理上禁止）を入力しています。
In case the packet is not discarded in the previous processing (either because the NAT64 is not filtering or because the packet is compliant with the Address-Dependent Filtering rule), then the NAT64 searches for the Session Table Entry containing the STE source IPv4 transport address equal to (T,t) and the STE destination IPv4 transport address equal to (W,w). If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit). In case a new UDP Session Table Entry is created, it contains the following information:
場合にパケットが前回の処理で廃棄されていない（どちらかのNAT64がフィルタリングされていないためか、パケットがアドレス依存フィルタリングルールに準拠しているため）、次いでNAT64はSTE元IPv4トランスポートアドレスを含むセッションテーブルエントリを検索し（T、t）と等しいSTE先IPv4トランスポートアドレス（W、W）に等しいです。そのようなエントリが見つからない場合、NAT64は新しいエントリを作成しよう（リソースおよびポリシーを許可する場合）。新しいUDPセッションテーブルエントリが作成される場合は、次の情報が含まれます。
* The STE source IPv6 transport address is extracted from the corresponding UDP BIB entry.
* STE元IPv6トランスポートアドレスは、対応するUDP BIBエントリから抽出されます。
* The STE destination IPv6 transport address is set to (Y'(W),w), w being the same port w as the source IPv4 transport address and Y'(W) being the IPv6 representation of W, generated using the algorithm described in Section 3.5.4.
* STE宛先IPv6トランスポートアドレス（W）WのIPv6の表現である「ソースIPv4トランスポートアドレス及びYはW同じポートであるwは、（（W）、W Y）」に設定され、説明されたアルゴリズムを使用して生成3.5.4インチ
* The STE source IPv4 transport address is set to (T,t), i.e., the destination IPv4 transport addresses contained in the received IPv4 packet.
* STE元IPv4トランスポートアドレスは、すなわち（T、t）は、受信したIPv4パケットに含まれる宛先IPv4トランスポートアドレスに設定されています。
* The STE destination IPv4 transport is set to (W,w), i.e., the source IPv4 transport addresses contained in the received IPv4 packet.
* STE先IPv4トランスポートに設定されている（W、W）、すなわち、受信したIPv4パケットに含まれる送信元IPv4トランスポート・アドレス。
The NAT64 sets (or resets) the timer in the Session Table Entry to the maximum session lifetime. The maximum session lifetime MAY be configurable, and the default SHOULD be at least UDP_DEFAULT. The maximum session lifetime MUST NOT be less than UDP_MIN. The packet is translated and forwarded as described in the following sections.
NAT64セット（またはリセット）最大セッション存続時間にセッションテーブルエントリのタイマ。最大セッション存続期間は設定可能であり、デフォルトでは、少なくともUDP_DEFAULTであるべきです。最大セッション寿命はUDP_MIN以上でなければなりません。次のセクションで説明したように、パケットは、翻訳され転送されます。
When a new UDP BIB entry is created for a source transport address of (S',s), the NAT64 allocates an IPv4 transport address for this BIB entry as follows:
新しいUDP BIBエントリが（S」、S）のソース輸送アドレスのために作成された場合、以下のように、NAT64はこのBIBエントリのIPv4トランスポートアドレスを割り当てます。
If there exists some other BIB entry containing S' as the IPv6 address and mapping it to some IPv4 address T, then the NAT64 SHOULD use T as the IPv4 address. Otherwise, use any IPv4 address of the IPv4 pool assigned to the NAT64 to be used for translation.
いくつかの他のBIBエントリのIPv6アドレスとしてS「を含む、いくつかのIPv4アドレスTにマッピングが存在する場合、NAT64は、IPv4アドレスとしてTを使用すべきです。それ以外の場合は、変換に使用するNAT64に割り当てられたIPv4プールの任意のIPv4アドレスを使用します。
If the port s is in the Well-Known port range 0-1023, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port. (This behavior is recommended in REQ 3-a of [RFC4787].)
ポートsは既知のポート範囲0〜1023であり、かつNAT64は、同じポート範囲で使用可能なポートのトンを持っている場合は、NAT64は、ポートTを割り当てる必要があります。 NAT64は、同じ範囲で利用可能なポートがない場合は、NAT64は、それが利用可能なポートを持っている別の範囲からポートTを割り当てることができます。 （この動作は[RFC4787]のREQ 3-Aで推奨されています。）
If the port s is in the range 1024-65535, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port. (This behavior is recommended in REQ 3-a of [RFC4787].)
ポートの範囲1024〜65535であり、NAT64は、同じポート範囲で使用可能なポートtを有する場合、NAT64は、ポートTを割り当てなければなりません。 NAT64は、同じ範囲で利用可能なポートがない場合は、NAT64は、それが利用可能なポートを持っている別の範囲からポートTを割り当てることができます。 （この動作は[RFC4787]のREQ 3-Aで推奨されています。）
The NAT64 SHOULD preserve the port parity (odd/even), as per Section 4.2.2 of [RFC4787]).
NAT64は、[RFC4787]）のセクション4.2.2に従って、ポートパリティ（奇数/偶数）を維持すべきです。
In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the UDP and TCP BIBs).
全ての場合において、割り当てられたIPv4トランスポートアドレス（T、t）は同じBIB内の別のエントリで使用中であってはなりませんが、他のビブ（例えば、UDPやTCPよだれ掛け）における使用であることができます。
If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable).
それは適切なIPv4トランスポートアドレスを割り当てるか、BIBエントリを作成することができない場合、パケットは破棄されます。 NAT64は、コード3（アドレス到達不能）とのICMPv6宛先到達不能エラーメッセージを送信する必要があります。
In this section, we describe how the TCP BIB and session table are populated. We do so by defining the state machine that the NAT64 uses for TCP. We first describe the states and the information contained in them, and then we describe the actual state machine and state transitions.
このセクションでは、TCP BIBとセッションテーブルが移入されている方法について説明します。私たちは、NAT64は、TCPのために使用するステートマシンを定義することによって行います。私たちは、最初の状態と、それらに含まれる情報を記述した後、我々は実際の状態マシンと状態遷移を説明します。
The following state information is stored for a TCP session:
次の状態情報は、TCPセッションのために保存されます。
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
結合：（X 'X）、（Y'、Y）< - >（T、T）、（Z、Z）
Lifetime: a timer that tracks the remaining lifetime of the TCP session. When the timer expires, the TCP session is deleted. If all the TCP sessions corresponding to a TCP BIB entry are deleted, then the dynamically created TCP BIB entry is also deleted.
生涯：TCPセッションの残りの寿命を追跡するタイマー。タイマーが満了すると、TCPセッションが削除されます。 TCP BIBエントリに対応するすべてのTCPセッションが削除された場合は、動的に作成されたTCP BIBエントリも削除されます。
Because the TCP session inactivity lifetime is set to at least 2 hours and 4 minutes (as per [RFC5382]), it is important that each TCP Session Table Entry corresponds to an existing TCP session. In order to do that, for each TCP session established, the TCP connection state is tracked using the following state machine.
TCPセッションが非アクティブの寿命は（[RFC5382]に従って）少なくとも2時間及び4分に設定されているので、各TCPセッションテーブルエントリは、既存のTCPセッションに対応することが重要です。各TCPセッションが確立のためにそれを行うためには、TCP接続状態は以下のステート・マシンを使用して追跡されます。
The states are as follows:
次のように状態は以下のとおりです。
CLOSED: Analogous to [RFC0793], CLOSED is a fictional state because it represents the state when there is no state for this particular 5-tuple, and therefore no connection.
CLOSED：なし状態が、この特定の5タプル、したがってない接続のために存在しない場合、それは状態を表すので、[RFC0793]と同様に、CLOSEDは架空の状態です。
V4 INIT: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side. The NAT64 is now waiting for a matching IPv6 packet containing the TCP SYN in the opposite direction.
V4のINIT：TCP SYNを含むIPv4パケットは、TCP接続がIPv4側から開始されていることを意味する、NAT64によって受信されました。 NAT64は今や反対方向にTCP SYNを含む一致IPv6パケットを待っています。
V6 INIT: An IPv6 packet containing a TCP SYN was received, translated, and forwarded by the NAT64, implying that a TCP connection is being initiated from the IPv6 side. The NAT64 is now waiting for a matching IPv4 packet containing the TCP SYN in the opposite direction.
V6 INIT：TCP SYNを含むIPv6パケットは、受信された翻訳、およびNAT64によって転送、TCPコネクションがIPv6側から開始されていることを示唆しました。 NAT64は今や反対方向にTCP SYNを含む一致IPv4パケットを待っています。
ESTABLISHED: Represents an open connection, with data able to flow in both directions.
ESTABLISHED：両方向に流れることができるデータとのオープン接続を表します。
V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection, and the NAT64 is waiting for a matching TCP FIN in the opposite direction.
V4 FIN RCV：TCP FINを含むIPv4パケットは、NAT64によって受信された、データがまだ接続に流れることができる、とNAT64が反対方向に整合するTCP FINを待っています。
V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection, and the NAT64 is waiting for a matching TCP FIN in the opposite direction.
V6 FIN RCV：TCP FINを含むIPv6パケットは、NAT64によって受信された、データがまだ接続に流れることができる、とNAT64が反対方向に整合するTCP FINを待っています。
V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and an IPv6 packet containing an TCP FIN for this connection were received by the NAT64. The NAT64 keeps the connection state alive and forwards packets in both directions for a short period of time to allow remaining packets (in particular, the ACKs) to be delivered.
V6 FIN + V4 FIN RCV：TCP FINを含むIPv4パケットと、この接続のためにTCP FINを含むIPv6パケットの両方がNAT64によって受信されました。 NAT64は、生きている接続状態を維持し、（特に、ACKの）残りのパケットが配信されることを可能にする短時間の両方向にパケットを転送します。
TRANS: The lifetime of the state for the connection is set to TCP_TRANS minutes either because a packet containing a TCP RST was received by the NAT64 for this connection or simply because the lifetime of the connection has decreased and there are only TCP_TRANS minutes left. The NAT64 will keep the state for the connection for TCP_TRANS minutes, and if no other data packets for that connection are received, the state for this connection is then terminated.
TRANS：接続のための状態の寿命はTCP_TRANS分TCP RSTを含むパケットは、この接続のためにNAT64によって受信された又は接続の寿命が低下していると左のみTCP_TRANS分が存在するというだけの理由のいずれかのために設定されています。 NAT64はTCP_TRANS分の接続の状態を維持し、その接続のための他のデータパケットが受信されない場合は、この接続の状態を終了します。
The state machine used by the NAT64 for the TCP session processing is depicted next. The described state machine handles all TCP segments received through the IPv6 and IPv4 interface. There is one state machine per TCP connection that is potentially established through the NAT64. After bootstrapping of the NAT64 device, all TCP sessions are in CLOSED state. As we mention above, the CLOSED state is a fictional state when there is no state for that particular connection in the NAT64. It should be noted that there is one state machine per connection, so only packets belonging to a given connection are inputs to the state machine associated to that connection. In other words, when in the state machine below we state that a packet is received, it is implicit that the incoming 5-tuple of the data packet matches to the one of the state machine.
TCPセッション処理のためにNAT64によって使用されるステートマシンは次示されています。この状態マシンは、IPv6とIPv4インタフェースを介して受信したすべてのTCPセグメントを処理します。潜在的にNAT64を介して確立されたTCPコネクションごとに1台のステートマシンがあります。 NAT64デバイスのブートストラップの後、すべてのTCPセッションがCLOSED状態になっています。我々は上記に言及したようNAT64でその特定の接続のための状態が存在しない場合、CLOSED状態は架空の状態があります。接続ごとに状態機械があるので、所与の接続に属するパケットのみが、その接続に関連する状態マシンへの入力であることに留意すべきです。ステートマシンで、我々はパケットを受信した状態の下換言すれば、データ・パケットの着信5タプルは、状態マシンのいずれかに一致していることを暗黙です。
A TCP segment with the SYN flag set that is received through the IPv6 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST, and V4 RST.
IPv6インタフェースを介して受信されたSYNフラグが設定されたTCPセグメントがV4 SYN、FIN V4、V6 FIN、FIN V6 + V4 FIN、V6 RST、及びV4 RST、同様に、V6 SYNと呼ばれます。
The figure presents a simplified version of the state machine; refer to the text for the full specification of the state machine.
図は、ステートマシンの簡易版を提示します。ステート・マシンの完全な仕様のためのテキストを参照してください。
+-----------------------------+
| |
V |
V6 +------+ V4 |
+----SYN------|CLOSED|-----SYN------+ |
| +------+ | |
| ^ | |
| |TCP_TRANS T.O. | |
V | V |
+-------+ +-------+ +-------+ |
|V6 INIT| | TRANS | |V4 INIT| |
+-------+ +-------+ +-------+ |
| | ^ | |
| data pkt | | |
| | V4 or V6 RST | |
| | TCP_EST T.O. | |
V4 SYN V | V6 SYN |
| +--------------+ | |
+--------->| ESTABLISHED |<---------+ |
+--------------+ |
| | |
V4 FIN V6 FIN |
| | |
V V |
+---------+ +----------+ |
| V4 FIN | | V6 FIN | |
| RCV | | RCV | |
+---------+ +----------+ |
| | |
V6 FIN V4 FIN TCP_TRANS
| | T.O.
V V |
+---------------------+ |
| V4 FIN + V6 FIN RCV |--------------------+
+---------------------+
We next describe the state information and the transitions.
私たちは、次の状態の情報と遷移を説明します。
*** CLOSED ***
*** 閉まっている ***
If a V6 SYN is received with an incoming tuple with source transport address (X',x) and destination transport address (Y',y) (this is the case of a TCP connection initiated from the IPv6 side), the processing is as follows:
V6 SYNがソーストランスポートアドレス（X「X）と宛先トランスポートアドレス（Y」、Y）（これは、IPv6側から開始されたTCP接続の場合である）の着信タプルで受信された場合、処理はとおりであります次のとおりです。
1. The NAT64 searches for a TCP BIB entry that matches the IPv6 source transport address (X',x).
1. NAT64は、IPv6ソーストランスポートアドレス（X」、X）と一致TCP BIBエントリを検索します。
If such an entry does not exist, the NAT64 tries to create a
new BIB entry (if resources and policy permit). The BIB IPv6
transport address is set to (X',x), i.e., the source IPv6
transport address of the packet. The BIB IPv4 transport
address is set to an IPv4 transport address allocated using
the rules defined in Section 3.5.2.3. The processing of the
packet continues as described in bullet 2.
If the entry already exists, then the processing continues as described in bullet 2.
エントリがすでに存在する場合弾丸2に記載されているように、処理が継続されます。
2. Then the NAT64 tries to create a new TCP session entry in the TCP session table (if resources and policy permit). The information included in the session table is as follows:
2.次に、NAT64は（リソースやポリシーが許す場合）TCPセッションテーブルに新しいTCPセッションのエントリを作成しようとします。次のようにセッションテーブルに含まれる情報は以下のとおりです。
The STE source IPv6 transport address is set to (X',x), i.e.,
the source transport address contained in the received V6 SYN
packet.
The STE destination IPv6 transport address is set to (Y',y), i.e., the destination transport address contained in the received V6 SYN packet.
STE宛先IPv6トランスポートアドレスは、すなわち（Y」、Y）、受信したV6 SYNパケットに含まれる宛先のトランスポートアドレスに設定されています。
The STE source IPv4 transport address is set to the BIB IPv4 transport address of the corresponding TCP BIB entry.
STE元IPv4トランスポートアドレスは、対応するTCP BIBエントリのBIB IPv4トランスポートアドレスに設定されています。
The STE destination IPv4 transport address contains the port y (i.e., the same port as the IPv6 destination transport address) and the IPv4 address that is algorithmically generated from the IPv6 destination address (i.e., Y') using the reverse algorithm as specified in Section 3.5.4.
STE先のIPv4トランスポート・アドレスは、ポートYを含み（すなわち、IPv6の宛先トランスポートアドレスと同じポート）とセクションで指定されるようにアルゴリズムの逆のアルゴリズムを使用して、IPv6宛先アドレス（すなわち、Y '）から生成されたIPv4アドレス3.5.4。
The lifetime of the TCP Session Table Entry is set to at least TCP_TRANS (the transitory connection idle timeout as defined in [RFC5382]).
TCPセッションテーブルエントリの寿命は少なくともTCP_TRANS（[RFC5382]で定義されるように一時的接続のアイドルタイムアウト）に設定されています。
4. The NAT64 translates and forwards the packet as described in the following sections.
4. NAT64に変換し、次のセクションで説明したようにパケットを転送します。
If a V4 SYN packet is received with an incoming tuple with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x) (this is the case of a TCP connection initiated from the IPv4 side), the processing is as follows:
V4 SYNパケットが送信元IPv4トランスポートアドレス（Y、Y）と宛先IPv4トランスポートアドレスを持つ着信タプルで受信された場合（X、X）（これは、IPv4側から開始されたTCP接続の場合である）、処理であります次のように：
If the security policy requires silently dropping externally initiated TCP connections, then the packet is silently discarded.
セキュリティポリシーは、外部から開始されたTCP接続をドロップ静かに必要な場合、パケットは黙って破棄されます。
Else, if the destination transport address contained in the incoming V4 SYN (i.e., X,x) is not in use in the TCP BIB, then:
そうでなければ、着信V4 SYNに含まれる宛先のトランスポートアドレス（すなわち、X、x）は、TCP BIBで使用中次にない場合。
The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy permit), containing the following information:
NAT64は、以下の情報を含む、（リソースおよびポリシーの許可場合）TCPセッションテーブルに新しいセッションテーブルエントリを作成しようとします：
+ The STE source IPv4 transport address is set to (X,x), i.e., the destination transport address contained in the V4 SYN.
+ STE元IPv4トランスポートアドレスは（X、X）V4 SYNに含まれている、すなわち、先のトランスポートアドレスに設定されています。
+ The STE destination IPv4 transport address is set to (Y,y), i.e., the source transport address contained in the V4 SYN.
+ STE先IPv4トランスポートアドレスはSYN V4に含まれる、すなわち、ソーストランスポートアドレス、（Y、Y）に設定されています。
+ The STE transport IPv6 source address is left unspecified and may be populated by other protocols that are out of the scope of this specification.
+ STE輸送IPv6ソースアドレスが未指定され、この明細書の範囲外である他のプロトコルによって移入することができます。
+ The STE destination IPv6 transport address contains the port y (i.e., the same port as the STE destination IPv4 transport address) and the IPv6 representation of Y (i.e., the IPv4 address of the STE destination IPv4 transport address), generated using the algorithm described in Section 3.5.4.
+ STE宛先IPv6トランスポートアドレスがポートYを含み（すなわち、STE先IPv4トランスポートアドレスと同じポート）を生成してY（すなわち、STE先IPv4トランスポートアドレスのIPv4アドレス）のIPv6の表現は、アルゴリズムを使用して3.5.4項で説明しました。
The state is moved to V4 INIT.
状態はV4 INITに移動されます。
The lifetime of the STE entry is set to TCP_INCOMING_SYN as per [RFC5382], and the packet is stored. The result is that the NAT64 will not drop the packet based on the filtering, nor create a BIB entry. Instead, the NAT64 will only create the Session Table Entry and store the packet. The motivation for this is to support simultaneous open of TCP connections.
STEエントリの寿命は[RFC5382]に従ってTCP_INCOMING_SYNに設定され、パケットが格納されます。結果は、NAT64は、フィルタリングに基づいてパケットをドロップし、またBIBエントリを作成しないことです。代わりに、NAT64は、セッションテーブルエントリを作成して、パケットを格納します。この動機は、TCPコネクションの同時オープンをサポートすることです。
If the destination transport address contained in the incoming V4 SYN (i.e., X,x) is in use in the TCP BIB, then:
宛先トランスポートアドレスが着信V4 SYNに含まれている場合（すなわち、Xは、X）をTCP BIB、に使用されています。
The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy permit), containing the following information:
NAT64は、以下の情報を含む、（リソースおよびポリシーの許可場合）TCPセッションテーブルに新しいセッションテーブルエントリを作成しようとします：
+ The STE source IPv4 transport address is set to (X,x), i.e., the destination transport address contained in the V4 SYN.
+ STE元IPv4トランスポートアドレスは（X、X）V4 SYNに含まれている、すなわち、先のトランスポートアドレスに設定されています。
+ The STE destination IPv4 transport address is set to (Y,y), i.e., the source transport address contained in the V4 SYN.
+ STE先IPv4トランスポートアドレスはSYN V4に含まれる、すなわち、ソーストランスポートアドレス、（Y、Y）に設定されています。
+ The STE transport IPv6 source address is set to the IPv6 transport address contained in the corresponding TCP BIB entry.
+ STE輸送IPv6ソースアドレスは、対応するTCP BIBエントリに含まれるIPv6トランスポートアドレスに設定されています。
+ The STE destination IPv6 transport address contains the port y (i.e., the same port as the STE destination IPv4 transport address) and the IPv6 representation of Y (i.e., the IPv4 address of the STE destination IPv4 transport address), generated using the algorithm described in Section 3.5.4.
+ STE宛先IPv6トランスポートアドレスがポートYを含み（すなわち、STE先IPv4トランスポートアドレスと同じポート）を生成してY（すなわち、STE先IPv4トランスポートアドレスのIPv4アドレス）のIPv6の表現は、アルゴリズムを使用して3.5.4項で説明しました。
The state is moved to V4 INIT.
状態はV4 INITに移動されます。
If the NAT64 is performing Address-Dependent Filtering, the lifetime of the STE entry is set to TCP_INCOMING_SYN as per [RFC5382], and the packet is stored. The motivation for creating the Session Table Entry and storing the packet (instead of simply dropping the packet based on the filtering) is to support simultaneous open of TCP connections.
NAT64は、アドレス依存フィルタリングを実行している場合には、STEエントリの寿命は[RFC5382]に従ってTCP_INCOMING_SYNに設定され、パケットが格納されます。セッションテーブルエントリを作成し、パケットを格納する（代わりに、単にフィルタリングに基づいてパケットをドロップ）するための動機は、TCP接続の同時開放を支援することです。
If the NAT64 is not performing Address-Dependent Filtering, the lifetime of the STE is set to at least TCP_TRANS (the transitory connection idle timeout as defined in [RFC5382]), and it translates and forwards the packet as described in the following sections.
NAT64は、アドレス依存フィルタリングを実行していない場合には、STEの寿命が少なくともTCP_TRANSに設定されている（[RFC5382]で定義されるように一時的接続のアイドルタイムアウト）、それは変換し、次のセクションで説明したようにパケットを転送します。
For any other packet belonging to this connection:
この接続に属する他のパケットの場合：
If there is a corresponding entry in the TCP BIB, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
TCP BIB内の対応するエントリが存在する場合、パケットは翻訳する必要があり、セキュリティポリシーがそうすることができた場合に転送されます。状態は変わりません。
If there is no corresponding entry in the TCP BIB, the packet is silently discarded.
TCP BIBに対応するエントリがない場合、パケットは黙って破棄されます。
*** V4 INIT ***
RFのINIT *** ***
If a V6 SYN is received with incoming tuple with source transport address (X',x) and destination transport address (Y',y), then the lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The packet is translated and forwarded. The state is moved to ESTABLISHED.
V6 SYN着信ソーストランスポートアドレスを持つタプルで受信された場合（X「X）と宛先トランスポートアドレス（Y」、Y）、次に、TCPセッションテーブルエントリの寿命は、少なくとも最大セッション存続時間に設定されています。最大セッション存続時間の値は設定可能であるが、それはTCP_EST未満であってはならない（[RFC5382]で定義されるように確立された接続アイドルタイムアウト）。最大セッションの有効期間のデフォルト値はTCP_ESTに設定する必要があります。パケットは翻訳して転送されます。状態が確立へ移動します。
If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 3) containing the IPv4 SYN packet stored is sent back to the source of the v4 SYN, the Session Table Entry is deleted, and the state is moved to CLOSED.
寿命が満了した場合、記憶されているIPv4のSYNパケットを含むICMPポート到達不能エラー（タイプ3、コード3）はバックV4のSYNのソースに送信され、セッションテーブルエントリが削除され、状態がCLOSEDに移動されます。
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
他のパケットの場合、パケットは変換され、セキュリティポリシーがそうすることができた場合に転送する必要があります。状態は変わりません。
*** V6 INIT ***
*** V6 HEAT ***
If a V4 SYN is received (with or without the ACK flag set), with an incoming tuple with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x), then the state is moved to ESTABLISHED. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The packet is translated and forwarded.
V4 SYNが（ACKフラグセットの有無にかかわらず）、受信された場合、ソースIPv4トランスポートアドレス（Y、Y）と宛先IPv4トランスポートアドレスを持つ着信タプルで（X、X）、次いで、状態が確立に移動されます。 TCPセッションテーブルエントリの寿命は、少なくとも最大セッション存続時間に設定されています。最大セッション存続時間の値は設定可能であるが、それはTCP_EST未満であってはならない（[RFC5382]で定義されるように確立された接続アイドルタイムアウト）。最大セッションの有効期間のデフォルト値はTCP_ESTに設定する必要があります。パケットは翻訳して転送されます。
If the lifetime expires, the Session Table Entry is deleted, and the state is moved to CLOSED.
寿命が満了した場合、セッションテーブルエントリが削除され、状態がCLOSEDに移動されます。
If a V6 SYN packet is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least TCP_TRANS. The state remains unchanged.
V6 SYNパケットを受信した場合、パケットは翻訳して転送されます。 TCPセッションテーブルエントリの寿命は少なくともTCP_TRANSに設定されています。状態は変わりません。
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
他のパケットの場合、パケットは変換され、セキュリティポリシーがそうすることができた場合に転送する必要があります。状態は変わりません。
*** ESTABLISHED ***
*** 設立 ***
If a V4 FIN packet is received, the packet is translated and forwarded. The state is moved to V4 FIN RCV.
V4 FINパケットを受信した場合、パケットは翻訳して転送されます。状態はV4 FIN RCVに移動されます。
If a V6 FIN packet is received, the packet is translated and forwarded. The state is moved to V6 FIN RCV.
V6 FINパケットを受信した場合、パケットは翻訳して転送されます。状態はV6 FIN RCVに移動されます。
If a V4 RST or a V6 RST packet is received, the packet is translated and forwarded. The lifetime is set to TCP_TRANS and the state is moved to TRANS. (Since the NAT64 is uncertain whether the peer will accept the RST packet, instead of moving the state to CLOSED, it moves to TRANS, which has a shorter lifetime. If no other packets are received for this connection during the short timer, the NAT64 assumes that the peer has accepted the RST packet and moves to CLOSED. If packets keep flowing, the NAT64 assumes that the peer has not accepted the RST packet and moves back to the ESTABLISHED state. This is described below in the TRANS state processing description.)
V4 RSTまたはV6 RSTパケットを受信した場合、パケットは翻訳して転送されます。寿命はTCP_TRANSに設定され、状態がTRANSに移動されます。 （NAT64が不明であるため、ピアは、それが短い寿命を有するTRANS、に移動し、代わりにCLOSEDの状態を移動させる、RSTパケットを受け入れるかどうか。他のパケットは、短いタイマー中にこの接続のために受信されない場合、NAT64を。ピアがCLOSEDにRSTパケットと移動を受け入れたことを前提としていたパケットが流れ続ける場合、NAT64これはTRANS状態処理の説明に説明されている。ピアがRSTパケットを受け付けていないと仮定し、確立された状態に戻ります。 ）
If any other packet is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as ESTABLISHED.
他のパケットを受信した場合、パケットは翻訳して転送されます。 TCPセッションテーブルエントリの寿命は、少なくとも最大セッション存続時間に設定されています。最大セッション存続時間の値は設定可能であるが、それはTCP_EST未満であってはならない（[RFC5382]で定義されるように確立された接続アイドルタイムアウト）。最大セッションの有効期間のデフォルト値はTCP_ESTに設定する必要があります。 ESTABLISHEDような状態は変わりません。
If the lifetime expires, then the NAT64 SHOULD send a probe packet (as defined next) to at least one of the endpoints of the TCP connection. The probe packet is a TCP segment for the connection with no data. The sequence number and the acknowledgment number are set to zero. All flags but the ACK flag are set to zero. The state is moved to TRANS.
寿命が満了した場合、その後、NAT64は、TCP接続のエンドポイントの少なくとも一方に（次の定義された）プローブパケットを送信すべきです。プローブパケットはデータなしとの接続のためのTCPセグメントです。シーケンス番号と確認応答番号がゼロに設定されています。すべてのフラグが、ACKフラグがゼロに設定されています。状態はTRANSに移動されます。
Upon the reception of this probe packet, the endpoint will reply with an ACK containing the expected sequence number for that connection. It should be noted that, for an active connection, each of these probe packets will generate one packet from each end involved in the connection, since the reply of the first point to the probe packet will generate a reply from the other endpoint.
このプローブパケットを受信すると、エンドポイントは、その接続のための期待されるシーケンス番号を含むACKで応答します。プローブパケットの最初のポイントの応答が他のエンドポイントからの応答を生成するためのアクティブな接続のために、これらのプローブパケットのそれぞれは、接続に関与する各端部から一つのパケットを生成することに留意されたいです。
*** V4 FIN RCV ***
*** HF FIN RTSV ***
If a V6 FIN packet is received, the packet is translated and forwarded. The lifetime is set to TCP_TRANS. The state is moved to V6 FIN + V4 FIN RCV.
V6 FINパケットを受信した場合、パケットは翻訳して転送されます。寿命はTCP_TRANSに設定されています。状態はV6 FIN + V4 FIN RCVに移動されます。
If any packet other than the V6 FIN is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as V4 FIN RCV.
V6 FIN以外のパケットを受信した場合、パケットは翻訳して転送されます。 TCPセッションテーブルエントリの寿命は、少なくとも最大セッション存続時間に設定されています。最大セッション存続時間の値は設定可能であるが、それはTCP_EST未満であってはならない（[RFC5382]で定義されるように確立された接続アイドルタイムアウト）。最大セッションの有効期間のデフォルト値はTCP_ESTに設定する必要があります。状態はV4 FIN RCVとして変わりません。
If the lifetime expires, the Session Table Entry is deleted, and the state is moved to CLOSED.
寿命が満了した場合、セッションテーブルエントリが削除され、状態がCLOSEDに移動されます。
*** V6 FIN RCV ***
*** V6 FIN RCV ***
If a V4 FIN packet is received, the packet is translated and forwarded. The lifetime is set to TCP_TRANS. The state is moved to V6 FIN + V4 FIN RCV.
V4 FINパケットを受信した場合、パケットは翻訳して転送されます。寿命はTCP_TRANSに設定されています。状態はV6 FIN + V4 FIN RCVに移動されます。
If any packet other than the V4 FIN is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as V6 FIN RCV.
V4 FIN以外のパケットを受信した場合、パケットは翻訳して転送されます。 TCPセッションテーブルエントリの寿命は、少なくとも最大セッション存続時間に設定されています。最大セッション存続時間の値は設定可能であるが、それはTCP_EST未満であってはならない（[RFC5382]で定義されるように確立された接続アイドルタイムアウト）。最大セッションの有効期間のデフォルト値はTCP_ESTに設定する必要があります。状態はV6 FIN RCVとして変わりません。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
寿命が満了した場合、セッションテーブルエントリが削除され、状態がCLOSEDに移動されます。
*** V6 FIN + V4 FIN RCV ***
*** BID + HF FIN FIN RTSV ***
All packets are translated and forwarded.
すべてのパケットが翻訳して転送されます。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
寿命が満了した場合、セッションテーブルエントリが削除され、状態がCLOSEDに移動されます。
*** TRANS ***
*** TRANS ***
If a packet other than a RST packet is received, the lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state is moved to ESTABLISHED.
RSTパケット以外のパケットを受信した場合、TCPセッションテーブルエントリの寿命は、少なくとも最大セッション存続時間に設定されています。最大セッション存続時間の値は設定可能であるが、それはTCP_EST未満であってはならない（[RFC5382]で定義されるように確立された接続アイドルタイムアウト）。最大セッションの有効期間のデフォルト値はTCP_ESTに設定する必要があります。状態が確立へ移動します。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
寿命が満了した場合、セッションテーブルエントリが削除され、状態がCLOSEDに移動されます。
When a new TCP BIB entry is created for a source transport address of (S',s), the NAT64 allocates an IPv4 transport address for this BIB entry as follows:
新しいTCP BIBエントリが（S」、S）のソース輸送アドレスのために作成された場合、以下のように、NAT64はこのBIBエントリのIPv4トランスポートアドレスを割り当てます。
If there exists some other BIB entry in any of the BIBs that contains S' as the IPv6 address and maps it to some IPv4 address T, then T SHOULD be used as the IPv4 address. Otherwise, use any IPv4 address of the IPv4 pool assigned to the NAT64 to be used for translation.
IPv6アドレスとして「Sが含まれており、いくつかのIPv4アドレスTにマッピングビブのいずれかで他のいくつかのBIBのエントリが存在する場合、Tは、IPv4アドレスとして使用する必要があります。それ以外の場合は、変換に使用するNAT64に割り当てられたIPv4プールの任意のIPv4アドレスを使用します。
If the port s is in the Well-Known port range 0-1023, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port.
ポートsは既知のポート範囲0〜1023であり、かつNAT64は、同じポート範囲で使用可能なポートのトンを持っている場合は、NAT64は、ポートTを割り当てる必要があります。 NAT64は、同じ範囲で利用可能なポートがない場合は、NAT64は、それが利用可能なポートを持っている別の範囲からポートTを割り当てることができます。
If the port s is in the range 1024-65535, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port.
ポートの範囲1024〜65535であり、NAT64は、同じポート範囲で使用可能なポートtを有する場合、NAT64は、ポートTを割り当てなければなりません。 NAT64は、同じ範囲で利用可能なポートがない場合は、NAT64は、それが利用可能なポートを持っている別の範囲からポートTを割り当てることができます。
In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the UDP and TCP BIBs).
全ての場合において、割り当てられたIPv4トランスポートアドレス（T、t）は同じBIB内の別のエントリで使用中であってはなりませんが、他のビブ（例えば、UDPやTCPよだれ掛け）における使用であることができます。
If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable).
それは適切なIPv4トランスポートアドレスを割り当てるか、BIBエントリを作成することができない場合、パケットは破棄されます。 NAT64は、コード3（アドレス到達不能）とのICMPv6宛先到達不能エラーメッセージを送信する必要があります。
The following state information is stored for an ICMP Query session in the ICMP Query session table:
次の状態情報は、ICMPクエリーセッションテーブル内のICMPクエリーセッションのために記憶されます。
Binding:(X',Y',i1) <--> (T,Z,i2)
結合：（X 'Y'、I1）< - >（T、Z、I2）
Lifetime: a timer that tracks the remaining lifetime of the ICMP Query session. When the timer expires, the session is deleted. If all the ICMP Query sessions corresponding to a dynamically created ICMP Query BIB entry are deleted, then the ICMP Query BIB entry is also deleted.
寿命：ICMP問合せセッションの残りの寿命を追跡するタイマー。タイマーが満了すると、セッションが削除されます。動的に作成されたICMPクエリBIBエントリに対応するすべてのICMP問合せセッションが削除された場合は、ICMPクエリBIBエントリも削除されます。
An incoming ICMPv6 Informational packet with IPv6 source address X', IPv6 destination address Y', and ICMPv6 Identifier i1 is processed as follows:
次のようにIPv6ソースアドレスX「IPv6宛先アドレスY」、およびICMPv6の識別子I1の着信のICMPv6情報パケットが処理されます。
If the local security policy determines that ICMPv6 Informational packets are to be filtered, the packet is silently discarded. Else, the NAT64 searches for an ICMP Query BIB entry that matches the (X',i1) pair. If such an entry does not exist, the NAT64 tries to create a new entry (if resources and policy permit) with the following data:
ローカルセキュリティポリシーは、ICMPv6の情報パケットをフィルタリングすることを決定した場合、パケットは黙って破棄されます。そうでなければ、NAT64は、（X」、I1）のペアに一致するICMPクエリBIBエントリを検索します。そのようなエントリが存在しない場合は、NAT64は、新しいエントリを作成しようとすると、以下のデータを（リソースやポリシーが許すならば）：
* The BIB IPv6 address is set to X' (i.e., the source IPv6 address of the IPv6 packet).
* BIB IPv6アドレスがXに設定されている」（すなわち、IPv6パケットの送信元IPv6アドレス）。
* The BIB ICMPv6 Identifier is set to i1 (i.e., the ICMPv6 Identifier).
* BIB ICMPv6の識別子がI1に設定されている（すなわち、ICMPv6の識別子）。
* If there exists another BIB entry in any of the BIBs that contains the same IPv6 address X' and maps it to an IPv4 address T, then use T as the BIB IPv4 address for this new entry. Otherwise, use any IPv4 address assigned to the IPv4 interface.
*同じIPv6のアドレスX」が含まれており、TをIPv4アドレスにマッピングビブのいずれかで他のBIBエントリが存在する場合、この新しいエントリのBIB IPv4アドレスとしてTを使用しています。それ以外の場合は、IPv4インタフェースに割り当てられたIPv4アドレスを使用します。
* Any available value is used as the BIB ICMPv4 Identifier, i.e., any identifier value for which no other entry exists with the same (IPv4 address, ICMPv4 Identifier) pair.
*任意の利用可能な値がBIB ICMPv4の識別子、他のエントリが同じ（IPv4のアドレス、ICMPv4の識別子）ペアで存在しないため、すなわち、任意の識別子の値として使用されます。
The NAT64 searches for an ICMP Query Session Table Entry corresponding to the incoming 3-tuple (X',Y',i1). If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit). The information included in the new Session Table Entry is as follows:
NAT64は、着信3タプル（X「Y」、I1）に対応するICMPクエリセッションテーブルエントリを検索します。そのようなエントリが見つからない場合、NAT64は新しいエントリを作成しよう（リソースおよびポリシーを許可する場合）。次のように新しいセッションテーブルエントリに含まれる情報は以下のとおりです。
* The STE IPv6 source address is set to X' (i.e., the address contained in the received IPv6 packet).
* STE IPv6ソースアドレスがXに設定されている」（すなわち、受信したIPv6パケットに含まれるアドレス）。
* The STE IPv6 destination address is set to Y' (i.e., the address contained in the received IPv6 packet).
* STE IPv6宛先アドレスがYに設定されている」（すなわち、受信したIPv6パケットに含まれるアドレス）。
* The STE ICMPv6 Identifier is set to i1 (i.e., the identifier contained in the received IPv6 packet).
* STE ICMPv6の識別子がI1に設定されている（すなわち、受信したIPv6パケットに含まれる識別子）。
* The STE IPv4 source address is set to the IPv4 address contained in the corresponding BIB entry.
* STE IPv4ソースアドレスは、対応するBIBエントリに含まれるIPv4アドレスに設定されています。
* The STE ICMPv4 Identifier is set to the IPv4 identifier contained in the corresponding BIB entry.
* STE ICMPv4の識別子が対応BIBエントリに含まれるIPv4の識別子に設定されています。
* The STE IPv4 destination address is algorithmically generated from Y' using the reverse algorithm as specified in Section 3.5.4.
* STE IPv4宛先アドレスは、アルゴリズムセクション3.5.4で指定されるように、逆のアルゴリズムを用いて「Yから生成されます。
The NAT64 sets (or resets) the timer in the session table entry to the maximum session lifetime. By default, the maximum session lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be configurable. The packet is translated and forwarded as described in the following sections.
NAT64セット（またはリセット）最大セッション存続時間のセッション・テーブル・エントリ内のタイマー。デフォルトでは、最大セッション寿命はICMP_DEFAULTです。最大寿命値は設定可能であるべきです。次のセクションで説明したように、パケットは、翻訳され転送されます。
An incoming ICMPv4 Query packet with source IPv4 address Y, destination IPv4 address X, and ICMPv4 Identifier i2 is processed as follows:
次のように送信元IPv4アドレスY、宛先IPv4アドレスX、およびICMPv4の識別子I2の着信ICMPv4のクエリパケットが処理されます。
The NAT64 searches for an ICMP Query BIB entry that contains X as the IPv4 address and i2 as the ICMPv4 Identifier. If such an entry does not exist, the packet is dropped. An ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3, Code 1 (Host Unreachable).
NAT64はICMPv4の識別子としてIPv4アドレスとi2とXが含まれているICMPクエリBIBエントリを検索します。そのようなエントリが存在しない場合、パケットはドロップされます。 ICMPエラーメッセージは、パケットの元の送信者に送ってもよいです。 ICMPエラーメッセージは、送信された場合、3、コード1（ホスト到達不能）を入力しています。
If the NAT64 filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the Address-Dependent Filtering rule. To do this, it searches for a Session Table Entry with an STE source IPv4 address equal to X, an STE ICMPv4 Identifier equal to i2, and a STE destination IPv4 address equal to Y. If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, then an ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited).
そのIPv4インタフェース上のNAT64フィルター場合、NAT64は、着信パケットがアドレス依存フィルタリングルールに従って許可されているかどうかを確認します。これを行うために、そのようなエントリが見つかった場合（複数あってもよいXに等しいSTE元IPv4アドレス、I2に等しいSTE ICMPv4の識別子、およびYに等しいSTE宛先IPv4アドレスとセッションテーブルエントリを検索し）ものよりも、パケット処理が継続されます。そうでない場合、パケットは破棄されます。パケットが破棄された場合は、ICMPエラーメッセージは、パケットの元の送信者に送ってもよいです。 ICMPエラーメッセージは、送信された場合、3（宛先到達不能）とコード13（通信管理上禁止）を入力しています。
In case the packet is not discarded in the previous processing steps (either because the NAT64 is not filtering or because the packet is compliant with the Address-Dependent Filtering rule), then the NAT64 searches for a Session Table Entry with an STE source IPv4 address equal to X, an STE ICMPv4 Identifier equal to i2, and a STE destination IPv4 address equal to Y. If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit) with the following information:
ケースでは、パケットは、前処理工程で廃棄されていない（どちらかのNAT64は、フィルタリングされていないか、またはパケットがアドレス依存フィルタリングルールに準拠しているのでため）、その後、NAT64は、STEの送信元IPv4アドレスを持つセッションテーブルエントリを検索しXに等しい、I2に等しいSTE ICMPv4の識別子、およびそのようなエントリが見つからない場合はYに等しくSTE先IPv4アドレスは、NAT64は、新しいエントリを作成しようとする（もしリソース及びポリシー許可）は、以下の情報を持ちます。
* The STE source IPv4 address is set to X.
* STEの送信元IPv4アドレスがXに設定されています
* The STE ICMPv4 Identifier is set to i2.
* STE ICMPv4の識別子をI2に設定されています。
* The STE destination IPv4 address is set to Y.
* STE宛先IPv4アドレスがYに設定されています
* The STE source IPv6 address is set to the IPv6 address of the corresponding BIB entry.
* STE元IPv6アドレスは、対応するBIBエントリのIPv6アドレスに設定されています。
* The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of the corresponding BIB entry.
* STE ICMPv6の識別子が対応BIBエントリのICMPv6の識別子に設定されています。
* The STE destination IPv6 address is set to the IPv6 representation of the IPv4 address of Y, generated using the algorithm described in Section 3.5.4.
* STE宛先IPv6アドレスは、セクション3.5.4で説明したアルゴリズムを用いて生成されたYのIPv4アドレスのIPv6の表現、に設定されています。
* The NAT64 sets (or resets) the timer in the session table entry to the maximum session lifetime. By default, the maximum session lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be configurable. The packet is translated and forwarded as described in the following sections.
* NAT64セット（またはリセット）最大セッション存続時間のセッション・テーブル・エントリ内のタイマー。デフォルトでは、最大セッション寿命はICMP_DEFAULTです。最大寿命値は設定可能であるべきです。次のセクションで説明したように、パケットは、翻訳され転送されます。
NAT64 supports multiple algorithms for the generation of the IPv6 representation of an IPv4 address and vice versa. The constraints imposed on the generation algorithms are the following:
NAT64は、IPv4アドレスとその逆のIPv6の表現を生成するための複数のアルゴリズムをサポートします。生成アルゴリズムに課せられた制約は以下のとおりであります：
The algorithm MUST be reversible, i.e., it MUST be possible to derive the original IPv4 address from the IPv6 representation.
アルゴリズム、すなわち、IPv6表現から元IPv4アドレスを導出することが可能でなければなりません、可逆的でなければなりません。
The input for the algorithm MUST be limited to the IPv4 address, the IPv6 prefix (denoted Pref64::/n) used in the IPv6 representations, and optionally a set of stable parameters that are configured in the NAT64 (such as a fixed string to be used as a suffix).
IPv6の表現に使用されるアルゴリズムの入力IPv6プレフィックスは（Pref64を付し:: / N）、IPv4アドレスに制限されなければならない、そして任意に、へ固定文字列としてNAT64に構成されている安定したパラメータ（のセット）接尾辞として使用されます。
If we note n the length of the prefix Pref64::/n, then n MUST be less than or equal to 96. If a Pref64::/n is configured through any means in the NAT64 (such as manually configured, or other automatic means not specified in this document), the default algorithm MUST use this prefix. If no prefix is available, the algorithm SHOULD use the Well-Known Prefix (64:ff9b::/96) defined in [RFC6052].
我々は接頭Pref64の長さをn要点場合:: / Nは、N Pref64場合未満又は96に等しくなければならない:: / N NAT64の任意の手段によって構成されている（例えば、手動で設定、または他の自動よう）この文書で指定されていないこと、デフォルトのアルゴリズムは、この接頭辞を使用しなければなりません。 [RFC6052]で定義された：（ff9b :: / 96 64）は接頭辞が使用できない場合、アルゴリズムは、よく知られているプレフィックスを使用すべきです。
NAT64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in Section 2.3 of [RFC6052]. The aforementioned algorithm SHOULD be used as default algorithm.
NAT64は、[RFC6052]のセクション2.3で定義されたIPv4アドレスのIPv6の表現を生成するためのアルゴリズムをサポートしなければなりません。前述のアルゴリズムがデフォルトのアルゴリズムとして使用する必要があります。
This step computes the outgoing tuple by translating the IP addresses and port numbers or ICMP Identifier in the incoming tuple.
このステップは、着信タプル内のIPアドレスとポート番号またはICMP識別子を変換することによって、発信タプルを計算します。
In the text below, a reference to a BIB means the TCP BIB, the UDP BIB, or the ICMP Query BIB, as appropriate.
以下の文章では、BIBへの参照は、必要に応じて、TCP BIB、UDP BIB、またはICMPクエリBIBを意味します。
NOTE: Not all addresses are translated using the BIB. BIB entries are used to translate IPv6 source transport addresses to IPv4 source transport addresses, and IPv4 destination transport addresses to IPv6 destination transport addresses. They are NOT used to translate IPv6 destination transport addresses to IPv4 destination transport addresses, nor to translate IPv4 source transport addresses to IPv6 source transport addresses. The latter cases are handled by applying the algorithmic transformation described in Section 3.5.4. This distinction is important; without it, hairpinning doesn't work correctly.
注：すべてのアドレスはBIBを使用して翻訳されるわけではありません。 BIBエントリはIPv6宛先トランスポートアドレスへのIPv4ソーストランスポートアドレス、およびIPv4宛先トランスポートアドレスへのIPv6ソーストランスポートアドレスを変換するために使用されています。彼らは、IPv4の宛先トランスポートアドレスへのIPv6の宛先トランスポートアドレスを変換するために、またIPv6のソーストランスポートアドレスへのIPv4ソーストランスポートアドレスを変換するために使用されていません。後者の場合は、セクション3.5.4に記載のアルゴリズム変換を適用することによって処理されます。この区別は重要です。それなしで、ヘアピンが正常に動作しません。
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and for ICMP Error Messages Containing a TCP or UDP Packets
3.6.1. TCPやUDPパケットを含むTCP、UDP、およびICMPのエラー・メッセージの発信5タプルを計算します
The transport protocol in the outgoing 5-tuple is always the same as that in the incoming 5-tuple. When translating from IPv4 ICMP to IPv6 ICMP, the protocol number in the last next header field in the protocol chain is set to 58 (IPv6-ICMP). When translating from IPv6 ICMP to IPv4 ICMP, the protocol number in the protocol field of the IP header is set to 1 (ICMP).
発信5タプルでトランスポートプロトコルは、常に着信5タプルと同様です。 IPv4のICMPからのIPv6 ICMPに変換するとき、プロトコル・チェーン内の最後の次のヘッダフィールド内のプロトコル番号が58（のIPv6 ICMP）に設定されています。 IPv6のICMPからのIPv4 ICMPに変換するとき、IPヘッダのプロトコルフィールドにプロトコル番号が1（ICMP）に設定されています。
When translating in the IPv6 --> IPv4 direction, let the source and destination transport addresses in the incoming 5-tuple be (S',s) and (D',d), respectively. The outgoing source transport address is computed as follows: if the BIB contains an entry (S',s) <--> (T,t), then the outgoing source transport address is (T,t).
IPv6では変換時 - > IPv4の方向を、着信5タプル内のソースおよび宛先トランスポートアドレスは、それぞれ「（D、（S D）、S）および」とします。次のように発信元トランスポート・アドレスが計算される。BIBは、（S」、S）エントリが含まれている場合< - >（T、t）を、次いで、発信元トランスポートアドレス（T、t）です。
The outgoing destination address is computed algorithmically from D' using the address transformation described in Section 3.5.4.
送信先アドレスは、セクション3.5.4に記載のアドレス変換を使用して、「Dからアルゴリズム的に計算されます。
When translating in the IPv4 --> IPv6 direction, let the source and destination transport addresses in the incoming 5-tuple be (S,s) and (D,d), respectively. The outgoing source transport address is computed as follows:
IPv4の変換時 - > IPv6の方向を、5タプルは、それぞれ、（S、S）及び（D、D）である着信のソースと宛先のトランスポートアドレスをしましょう。次のように、発信元トランスポートアドレスが計算されます。
The outgoing source transport address is generated from S using the address transformation algorithm described in Section 3.5.4.
発信元トランスポート・アドレスは、セクション3.5.4に記載したアドレス変換アルゴリズムを使用して、Sから生成されます。
The BIB table is searched for an entry (X',x) <--> (D,d), and if one is found, the outgoing destination transport address is set to (X',x).
'< - >が見つかった場合には（D、D）、および、送信先トランスポートアドレスに設定されている（X（X、X）BIBテーブルがX）' の項目が検索されます。
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages and for ICMP Error Messages Containing an ICMP Query
3.6.2. ICMPクエリーメッセージのためにとICMPクエリを含むICMPエラーメッセージの発信3タプルを計算します
When translating in the IPv6 --> IPv4 direction, let the source and destination addresses in the incoming 3-tuple be S' and D', respectively, and the ICMPv6 Identifier be i1. The outgoing source address is computed as follows: the BIB contains an entry (S',i1) <--> (T,i2), then the outgoing source address is T and the ICMPv4 Identifier is i2.
IPv6では変換時 - > IPv4の方向を、送信元および宛先アドレスは、S「およびD」はそれぞれ、およびICMPv6の識別子がI1であることが到来する3組にしましょう。次のように発信元アドレスが計算される：BIBエントリ（S」、I1）を含む< - >（T、I2）を、次いで、発信元アドレスはTであり、ICMPv4の識別子I2です。
The outgoing IPv4 destination address is computed algorithmically from D' using the address transformation described in Section 3.5.4.
発信IPv4宛先アドレスは、セクション3.5.4に記載のアドレス変換を使用して、「Dからアルゴリズム的に計算されます。
When translating in the IPv4 --> IPv6 direction, let the source and destination addresses in the incoming 3-tuple be S and D, respectively, and the ICMPv4 Identifier is i2. The outgoing source address is generated from S using the address transformation algorithm described in Section 3.5.4. The BIB is searched for an entry containing (X',i1) <--> (D,i2), and, if found, the outgoing destination address is X' and the outgoing ICMPv6 Identifier is i1.
IPv4の変換時 - > IPv6の方向、着信3タプル内のソースおよび宛先アドレスは、それぞれS及びD、であるとすると、ICMPv4の識別子I2です。発信元アドレスは、セクション3.5.4に記載のアドレス変換アルゴリズムを使用して、Sから生成されます。 BIBは、（Xを含むエントリが検索される「< - > I1）（D、I 2）を、そして、見つかった場合、送信先アドレスがXである」と発信のICMPv6識別子I1あります。
This step translates the packet from IPv6 to IPv4 or vice versa.
このステップは、パケットのIPv6からIPv4の、またはその逆に変換します。
The translation of the packet is as specified in Sections 4 and 5 of the IP/ICMP Translation Algorithm [RFC6145], with the following modifications:
以下の変更を加えて、IP / ICMP翻訳アルゴリズム[RFC6145]のセクション4および5で指定されたパケットの翻訳です。
o When translating an IP header (Sections 4.1 and 5.1 of [RFC6145]), the source and destination IP address fields are set to the source and destination IP addresses from the outgoing tuple as determined in Section 3.6.
IPヘッダ（セクション4.1と[RFC6145]の5.1）に変換する場合、セクション3.6で決定されるように、O、送信元および宛先IPアドレスフィールドは、発信タプルから送信元および宛先IPアドレスに設定されています。
o When the protocol following the IP header is TCP or UDP, then the source and destination ports are modified to the source and destination ports from the outgoing 5-tuple. In addition, the TCP or UDP checksum must also be updated to reflect the translated addresses and ports; note that the TCP and UDP checksum covers the pseudo-header that contains the source and destination IP addresses. An algorithm for efficiently updating these checksums is described in [RFC3022].
IPヘッダの次のプロトコルがTCPまたはUDPの場合、O、ソースおよび宛先ポートは、発信5タプルから送信元ポートと宛先ポートに変更されています。また、TCPやUDPチェックサムはまた、変換されたアドレスとポートを反映するために更新する必要があります。 TCPとUDPチェックサムは、送信元と宛先のIPアドレスが含まれている疑似ヘッダーをカバーしていることに注意してください。効率的に、これらのチェックサムを更新するためのアルゴリズムは、[RFC3022]に記載されています。
o When the protocol following the IP header is ICMP and it is an ICMP Query message, the ICMP Identifier is set to the one from the outgoing 3-tuple as determined in Section 3.6.2.
IPヘッダの次のプロトコルがICMPであり、それはICMPクエリメッセージである場合、セクション3.6.2において決定されるように、O、ICMP識別子が発信3タプルから1に設定されています。
o When the protocol following the IP header is ICMP and it is an ICMP error message, the source and destination transport addresses in the embedded packet are set to the destination and source transport addresses from the outgoing 5-tuple (note the swap of source and destination).
IPヘッダの次のプロトコルがICMPであり、それはICMPエラーメッセージである場合、O、埋め込まれたパケットの送信元と宛先のトランスポートアドレスは、（発信5タプルから宛先および送信元トランスポート・アドレスに設定されているソースのスワップを注意し先）。
The size of outgoing packets as well and the potential need for fragmentation is done according to the behavior defined in the IP/ ICMP Translation Algorithm [RFC6145].
同様に発信パケットのサイズと断片化のための潜在的な必要性は、IP / ICMP翻訳アルゴリズム[RFC6145]で定義された動作に従って行われます。
If the destination IP address of the translated packet is an IPv4 address assigned to the NAT64 itself, then the packet is a hairpin packet. Hairpin packets are processed as follows:
翻訳されたパケットの宛先IPアドレスは、NAT64自身に割り当てられたIPv4アドレスである場合、パケットはヘアピンパケットです。次のようにヘアピンパケットが処理されます。
o The outgoing 5-tuple becomes the incoming 5-tuple.
発信O 5タプルは、着信5タプルとなります。
o The packet is treated as if it was received on the outgoing interface.
それは、発信インターフェイス上で受信されたかのようにOパケットが処理されます。
o Processing of the packet continues at step 2 -- "Filtering and Updating Binding and Session Information" (Section 3.5).
パケットのO処理は、ステップ2で継続 - 「フィルタリングとバインドとセッション情報を更新する」（3.5節）。
UDP_MIN: 2 minutes (as defined in [RFC4787])
UDP_MIN：2分（[RFC4787]で定義されるように）
UDP_DEFAULT: 5 minutes (as defined in [RFC4787])
UDP_DEFAULT：5分（[RFC4787]で定義されるように）
TCP_TRANS: 4 minutes (as defined in [RFC5382])
TCP_TRANS：4分（[RFC5382]で定義されるように）
TCP_EST: 2 hours (The minimum lifetime for an established TCP session defined in [RFC5382] is 2 hours and 4 minutes, which is achieved by adding the 2 hours with this timer and the 4 minutes with the TCP_TRANS timer.)
TCP_EST：2時間（[RFC5382]で定義された確立されたTCPセッションの最小寿命がTCP_TRANSタイマと、このタイマで2時間4分を添加することによって達成され、2時間及び4分です。）
TCP_INCOMING_SYN: 6 seconds (as defined in [RFC5382])
TCP_INCOMING_SYN：6秒（[RFC5382]で定義されるように）
FRAGMENT_MIN: 2 seconds
FRAGMENT_MIN：2秒
ICMP_DEFAULT: 60 seconds (as defined in [RFC5508])
ICMP_DEFAULT：60秒（[RFC5508]で定義されるように）
Any protocols that protect IP header information are essentially incompatible with NAT64. This implies that end-to-end IPsec verification will fail when the Authentication Header (AH) is used (both transport and tunnel mode) and when ESP is used in transport mode. This is inherent in any network-layer translation mechanism. End-to-end IPsec protection can be restored, using UDP encapsulation as described in [RFC3948]. The actual extensions to support IPsec are out of the scope of this document.
IPヘッダ情報を保護する任意のプロトコルは、本質的にNAT64と互換性がありません。これは、認証ヘッダ（AH）は、（両方の輸送とトンネルモード）を使用した場合とESPは、トランスポートモードで使用される場合、エンドツーエンドのIPsec認証が失敗することを意味します。これは、任意のネットワーク層の変換メカニズムに固有のものです。エンドツーエンドのIPsec保護は、[RFC3948]に記載されているようにUDPカプセル化を使用して、復元することができます。 IPsecをサポートするための実際の拡張子は、この文書の範囲外です。
NAT64 creates binding state using packets flowing from the IPv6 side to the IPv4 side. In accordance with the procedures defined in this document following the guidelines defined in [RFC4787], a NAT64 MUST offer "Endpoint-Independent Mapping". This means:
NAT64は、IPv4側へのIPv6側から流れるパケットを使用して結合状態を作り出します。 [RFC4787]で定義されたガイドラインに従って、この文書で定義された手順に従い、NAT64は、「エンドポイント・独立マッピング」を提供しなければなりません。これの意味は：
For any IPv6 packet with source (S'1,s1) and destination (Pref64::D1,d1) that creates an external mapping to (S1,s1v4), (D1,d1), for any subsequent packet from (S'1,s1) to (Pref64::D2,d2) that creates an external mapping to (S2,s2v4), (D2,d2), within a given binding timer window,
（S'1から任意の後続パケットの（D1、D1）、（S1、s1v4）外部マッピングを作成し、ソース（S'1、S1）と宛先（Pref64 :: D1、D1）を持つIPv6パケットのための、S1）（Pref64 :: D2、D2）所与結合タイマーウィンドウ内（D2、D2）、（S2、s2v4）外部マッピングを作成し、へ
(S1,s1v4) = (S2,s2v4) for all values of D2,d2
（S1、s1v4）=（S2、s2v4）D2、D2の全ての値に対して
Implementations MAY also provide support for "Address-Dependent Mapping" as also defined in this document and following the guidelines defined in [RFC4787].
また、この文書で定義されて、[RFC4787]で定義されたガイドラインを以下のように実装はまた、「アドレス依存マッピング」のサポートを提供することができます。
The security properties, however, are determined by which packets the NAT64 filter allows in and which it does not. The security properties are determined by the filtering behavior and filtering configuration in the filtering portions of the NAT64, not by the address mapping behavior. For example:
そうでないフィルタがで可能にし、NAT64をパケットれるセキュリティ特性は、しかし、決定されます。セキュリティプロパティはなく、アドレスマッピング動作によってNAT64のフィルタリング部でフィルタリング動作及びフィルタリング設定によって決定されます。例えば：
Without filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will traverse the NAT64 gateway and be forwarded
to the IPv6 transport address that created the binding. However,
With filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will first be processed against the filtering rules. If the source IPv4 address is permitted, the packets will
be forwarded to the IPv6 transport address. If the source IPv4
address is explicitly denied -- or the default policy is to deny
all addresses not explicitly permitted -- then the packet will be
discarded. A dynamic filter may be employed whereby the filter
will only allow packets from the IPv4 address to which the
original packet that created the binding was sent. This means
that only the IPv4 addresses to which the IPv6 host has initiated
connections will be able to reach the IPv6 transport address, and
no others. This essentially narrows the effective operation of
the NAT64 device to an "Address-Dependent Mapping" behavior,
though not by its mapping behavior, but instead by its filtering
behavior.
As currently specified, the NAT64 only requires filtering traffic based on the 5-tuple. In some cases (e.g., statically configured mappings), this may make it easy for an attacker to guess. An attacker need not be able to guess other fields, e.g., the TCP sequence number, to get a packet through the NAT64. While such traffic might be dropped by the final destination, it does not provide additional mitigations against bandwidth/CPU attacks targeting the internal network. To avoid this type of abuse, a NAT64 MAY keep track of the sequence number of TCP packets in order to verify the proper sequencing of exchanged segments, in particular, those of the SYNs and the FINs.
現在指定されているように、NAT64はわずか5タプルに基づいてフィルタリングトラフィックが必要です。いくつかのケース（例えば、静的に設定されたマッピング）で、これは簡単に攻撃者が推測することがあります。攻撃者は、NAT64を介してパケットを取得するには、例えば、TCPシーケンス番号を他のフィールドを推測することはできませんする必要があります。そのようなトラフィックは、最終目的地で廃棄される可能性がありますが、それは、内部ネットワークを対象に、帯域幅/ CPU攻撃に対する追加的な緩和策を提供していません。虐待のこのタイプを避けるために、NAT64は、具体的には、交換されたセグメントの適切な順序付けを確認するためにのSYNとフィンのそれらをTCPパケットのシーケンス番号を追跡するかもしれません。
The NAT64 device itself is a potential victim of different types of attacks. In particular, the NAT64 can be a victim of DoS attacks. The NAT64 device has a limited number of resources that can be consumed by attackers creating a DoS attack. The NAT64 has a limited number of IPv4 addresses that it uses to create the bindings. Even though the NAT64 performs address and port translation, it is possible for an attacker to consume all the IPv4 transport addresses by sending IPv6 packets with different source IPv6 transport addresses. This attack can only be launched from the IPv6 side, since IPv4 packets are not used to create binding state. DoS attacks can also affect other limited resources available in the NAT64 such as memory or link capacity. For instance, it is possible for an attacker to launch a DoS attack on the memory of the NAT64 device by sending fragments that the NAT64 will store for a given period. If the number of fragments is high enough, the memory of the NAT64 could be exhausted. Similarly, a DoS attack against the NAT64 can be crafted by sending either V4 or V6 SYN packets that consume memory in the form of session and/or binding table entries. In the case of IPv4 SYNs the situation is aggravated by the requirement to also store the data packets for a given amount of time, requiring more memory from the NAT64 device. NAT64 devices MUST implement proper protection against such attacks, for instance, allocating a limited amount of memory for fragmented packet storage as specified in Section 3.4.
NAT64デバイス自体は、攻撃の異なる種類の潜在的な被害者です。特に、NAT64は、DoS攻撃の被害者することができます。 NAT64デバイスは、DoS攻撃を作成する攻撃者によって消費できるリソースの数が限られています。 NAT64は、IPv4の限られた数は、それがバインディングを作成するために使用するアドレスを持っています。 NAT64は、アドレスとポート変換を実行していても、攻撃者が異なるソースIPv6トランスポートアドレスを持つIPv6パケットを送信することによって、すべてのIPv4トランスポート・アドレスを消費することが可能です。 IPv4パケットがバインディング状態を作成するために使用されていないので、この攻撃は、IPv6の側から起動することができます。 DoS攻撃はまた、メモリやリンク容量としてNAT64で利用可能な他の限られたリソースに影響を与えることができます。攻撃者はNAT64は、一定期間保存するフラグメントを送信することによって、NAT64デバイスのメモリ上のDoS攻撃を起動するために例えば、それは可能です。断片の数が十分に高い場合、NAT64のメモリが枯渇することができます。同様に、NAT64に対するDoS攻撃は、セッションの形および/または結合テーブル・エントリ内のメモリを消費V4またはV6のいずれかSYNパケットを送信することによって細工することができます。 IPv4のSYNの場合の状況はまた、NAT64デバイスからより多くのメモリを必要とする、時間の所定量のデータパケットを格納するための要件によって悪化します。 NAT64デバイスは、セクション3.4で指定されるように断片化されたパケット記憶用メモリの制限された量を割り当てる、例えば、そのような攻撃に対して適切な保護を実装しなければなりません。
Another consideration related to NAT64 resource depletion refers to the preservation of binding state. Attackers may try to keep a binding state alive forever by sending periodic packets that refresh the state. In order to allow the NAT64 to defend against such attacks, the NAT64 MAY choose not to extend the session entry lifetime for a specific entry upon the reception of packets for that entry through the external interface. As described in the framework document [RFC6144], the NAT64 can be deployed in multiple scenarios, in some of which the Internet side is the IPv6 one, and in others of which the Internet side is the IPv4 one. It is then important to properly set which is the Internet side of the NAT64 in each specific configuration.
NAT64リソースの枯渇に関連する別の考慮事項は、結合状態の維持を意味します。攻撃者は、状態をリフレッシュ定期的にパケットを送信することによって、永遠に生きている結合状態を維持しようとするかもしれません。 NAT64は、そのような攻撃を防御することを可能にするために、NAT64は、外部インターフェースを介して、そのエントリのためのパケットを受信すると、特定のエントリのためのセッションエントリの寿命を延長しないことを選んでもよいです。フレームワークドキュメント[RFC6144]に記載されているように、NAT64は、インターネット側がIPv6一つであり、その他にインターネット側がIPv4一つであるのそのうちのいくつかでは、複数のシナリオで展開することができます。それぞれの具体的な構成でNAT64のインターネット側である適切に設定することが、その後は重要です。
If an IPv6-only client can guess the IPv4 binding address that will be created, it can use the IPv6 representation of that address as the source address for creating this binding. Then, any packet sent to the binding's IPv4 address could loop in the NAT64. This is prevented in the current specification by filtering incoming packets containing Pref64::/n in the source address, as described below.
IPv6専用クライアントが作成されるのIPv4アドレスバインディングを推測することができれば、それはこのバインディングを作成するための送信元アドレスとして、そのアドレスのIPv6の表現を使用することができます。その後、バインディングのIPv4アドレスに送信されたパケットは、NAT64のループでした。これは、以下に説明するように、:: / N送信元アドレスにPref64を含む着信パケットをフィルタリングすることにより、現在の仕様に防止されます。
Consider the following example:
次の例を考えてみます。
Suppose that the IPv4 pool is 192.0.2.0/24
IPv4のプールがあると仮定し192.0.2.0/24
Then, the IPv6-only client sends this to NAT64:
次に、IPv6のみのクライアントは、NAT64に送信します：
Source: [Pref64::192.0.2.1]:500
出典：[Pref64 :: 192.0.2.1]：500
Destination: any
目的地：任意の
The NAT64 allocates 192.0.2.1:500 as the IPv4 binding address. Now anything sent to 192.0.2.1:500, be it a hairpinned IPv6 packet or an IPv4 packet, could loop.
NAT64は、IPv4アドレスバインディングとして192.0.2.1:500割り当てます。今192.0.2.1:500に送信されたもの、それはヘアピンIPv6パケットまたはIPv4パケットで、できたループ。
It is not hard to guess the IPv4 address that will be allocated. First, the attacker creates a binding and uses (for example) Simple Traversal of the UDP Protocol through NAT (STUN) [RFC5389] to learn its external IPv4 address. New bindings will always have this address. Then, it uses a source port in the range 1-1023. This will increase the chances to 1/512 (since range and parity are preserved by NAT64 in UDP).
割り当てられますIPv4アドレスを推測することは難しいことではありません。まず、攻撃者はその外部IPv4アドレスを学習するNAT（STUN）[RFC5389]を介してUDPプロトコルの結合および使用（例えば）簡易トラバーサルを作成します。新しいバインディングは、常にこのアドレスを持つことになります。その後、それは範囲1から1023の送信元ポートを使用しています。 （範囲およびパリティがUDPでNAT64によって保存されているので）これは1/512にチャンスを増加します。
In order to address this vulnerability, the NAT64 MUST drop IPv6 packets whose source address is in Pref64::/n, as defined in Section 3.5.
セクション3.5で定義されるように、この脆弱性に対処するために、NAT64は、そのソースアドレスPref64である:: / N IPv6パケットをドロップしなければなりません。
George Tsirtsis Qualcomm tsirtsis@googlemail.com
ジョージTsirtsisクアルコムtsirtsis@googlemail.com
Greg Lebovitz Juniper gregory.ietf@gmail.com
グレッグLebovitzジュニパーgregory.ietf@gmail.com
Simon Perreault Viagenie simon.perreault@viagenie.ca
サイモン・ペローViagenie simon.perreault@viagenie.ca
Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno, Ranjana Rao, Lars Eggert, Senthil Sivakumar, Zhen Cao, Xiangsong Cui, Mohamed Boucadair, Dong Zhang, Bryan Ford, Kentaro Ebisawa, Charles Perkins, Magnus Westerlund, Ed Jankiewicz, David Harrington, Peter McCann, Julien Laganier, Pekka Savola, and Joao Damas reviewed the document and provided useful comments to improve it.
デーブターラー、ダン・ウィング、アルベルト・ガルシア・マルティネス、レイナルドPenno、Ranjanaラオ、ラースEggertの、Senthilさんシバクマー、ジェン曹操、Xiangsong崔、モハメドBoucadair、ドンチャン、ブライアン・フォード、健太郎海老沢、チャールズ・パーキンス、マグヌスウェスター、エドJankiewicz、デヴィッド・ハリントン、ピーター・マッキャン、ジュリアンLaganier、ペッカSavola、およびジョアンダマは、文書を検討し、それを改善するために有用なコメントを提供しました。
The content of the document was improved thanks to discussions with Christian Huitema, Fred Baker, and Jari Arkko.
文書の内容は、クリスチャンのHuitema、フレッド・ベイカー、とヤリArkkoと協議のおかげで改善しました。
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
マルセロBagnuloとIljitschバンBeijnumの一部トリロジー、その第七次フレームワーク計画の下で、欧州委員会でサポートされている研究プロジェクトによって資金を供給されています。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.とC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]グハ、S.、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNAT行動要件"、BCP 142、RFC 5382、2008年10月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、 "ICMPのためのNAT行動要件"、BCP 148、RFC 5508、2009年4月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、リード、D.、およびP. Trainaの、 "IPフラグメントフィルタリングのためのセキュリティの考慮事項"、RFC 1858、1995年10月。
[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月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]、RFC 3128、2001年6月・ミラー、I.、 "タイニーフラグメント攻撃（RFC 1858）のバリアントに対する保護"。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963] Heffner、J.、マティス、M.、およびB.チャンドラー、 "高速データレートでのIPv4の再構築エラー"、RFC 4963、2007年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]ローゼンバーグ、J.、マーイ、R.、マシューズ、P.、およびD.翼、 "NAT（STUN）のセッショントラバーサルユーティリティ"、RFC 5389、2008年10月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク"、RFC 6144、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI.バンBeijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNSの拡張"、RFC 6147、2011年4月。
Authors' Addresses
著者のアドレス
Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain
UC3MマルセロBagnuloのAv。大学30のレガネス、マドリード28911スペイン
Phone: +34-91-6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es/marcelo
電話：+ 34-91-6249500電子メール：marcelo@it.uc3m.es URI：http://www.it.uc3m.es/marcelo
Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario Canada
フィリップ・マシューズアルカテル・ルーセント600月の道オタワ、オンタリオ州カナダ
Phone: +1 613-592-4343 x224 EMail: philip_matthews@magma.ca
電話：+1 613-592-4343 x224電子メール：philip_matthews@magma.ca
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
IljitschバンBeijnum IMDEA Networksの星Avda。デルマールメディテラネオ、22のレガネス、マドリード28918スペイン
EMail: iljitsch@muada.com
メールアドレス：iljitsch@muada.com