[要約] RFC 6146は、IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコルの変換を行うための状態を持つNAT64に関するものです。このRFCの目的は、IPv6とIPv4の間での通信を可能にするために、アドレスとプロトコルの変換を提供することです。
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
ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳
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のみのクライアントがUnicast UDP、TCP、またはICMPを使用してIPv4サーバーに連絡できるようにするStateful Nat64翻訳について説明しています。NAT64翻訳者に割り当てられた1つ以上のパブリックIPv4アドレスは、複数のIPv6のみのクライアントで共有されます。Stateful 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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントは、IPv4-IPV6遷移とIPv4-IPV6共存のメカニズムであるStateful NAT64を指定します。DNS64 [RFC6147]とともに、これらの2つのメカニズムにより、IPv6のみのクライアントがIPv4のみのサーバーへの通信を開始することができます。また、IPv4とIPv6ノード間のピアツーピア通信も可能になります。ここでは、いずれかのエンドが既存のNAT-Traversal、Peer to-Peer通信技術（ICE）などのピアツーピア通信技術を使用すると、通信を開始できます[ICE）RFC5245]。Stateful Nat64は、Stateful 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.
Stateful Nat64は、IPv6パケットをIPv4パケットに変換するメカニズムであり、その逆です。翻訳は、[RFC6145]で定義されているIP/ICMP翻訳アルゴリズムに従ってパケットヘッダーを翻訳することによって行われます。IPv4ホストのIPv4アドレスは、[RFC6052]で定義されているアルゴリズムと、この特定の目的のためにStateful NAT64に割り当てられたIPv6プレフィックスを使用して、IPv6アドレスとのアルゴリズム的に変換されます。IPv6ホストのIPv6アドレスは、通常のネットワークアドレスポート変換（NAPT）マナー[RFC3022]にマッピングをインストールすることにより、IPv4アドレスとの間で翻訳されます。現在の仕様では、TCP、UDP、およびICMPトラフィックを運ぶUnicastパケットをStateful Nat64がどのように変換するかのみを定義しています。ストリーム制御伝送プロトコル（SCTP）、Datagram混雑制御プロトコル（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は、RRSからAAAAリソースレコード（RRS）を合成するメカニズムです。合成AAAA RRに含まれるIPv6アドレスは、[RFC6052]で定義された同じアルゴリズムを使用して、IPv4アドレスと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のみのアプリケーションを実行しているホストを使用することができます。）IPv4のみのサーバー（上記のIPv6のみのホストに類似している）への通信を開始する。
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のみのサーバーに接続したい可能性があります。Stateful NAT64およびDNS64メカニズムは、IPv6クライアントまたはIPv4サーバーのいずれにも変更を必要としないため、簡単に展開できます。
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のみのネットワークをIPv4のみのネットワークに接続するデバイスでのステートフルNAT64関数の展開のみと、IPv6のみのホストにアクセス可能ないくつかのDNS64対応名サーバーの展開とともに必要です。。アプリケーションシナリオの分析は[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は、氷[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-to-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:
o 使用されるフィルタリングポリシー（エンドポイントに依存しない、またはアドレス依存）に応じて、IPv4ノードが特定のIPv6ノードにセッションを開始できる場合があります。次のメカニズムのいずれかを介して：
* 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ノードがNATトラバーサル技術（ICEなど）を使用した場合にも当てはまります。
* 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.
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メカニズムは、（少なくとも）2つのインターフェイス、IPv4ネットワークに接続されたIPv4インターフェイス、およびIPv6ネットワークに接続されたIPv6インターフェイスを持つデバイスに実装されています。IPv4ネットワークにあるIPv6ネットワークで生成されたパケットは、IPv4ネットワークにある受信機のためにNAT64デバイスに向かってIPv6ネットワーク内でルーティングされます。NAT64はそれらを翻訳し、IPv4ネットワークを介してIPv4レシーバーにIPv4パケットとして転送します。逆は、IPv6レシーバーのIPv4ネットワークに接続されたホストによって生成されたパケットで行われます。ただし、NAT64は対称ではありません。IPv6-IPV4翻訳を実行できるようにするには、NAT64には状態が必要です。状態には、IPv6アドレスとTCP/UDPポート（以下IPv6輸送アドレスと呼ばれる）のIPv4アドレスとTCP/UDPポート（以下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で静的に構成されているか、IPv6ネットワークからIPv4ネットワークに流れる最初のパケットが翻訳されたときに作成されます。結合状態が作成された後、その特定のフローの両方向に流れるパケットが翻訳されます。その結果、一般的なケースでは、NAT64はIPv6のみのノードによって開始されたIPv4のみのノードに向けて開始された通信のみをサポートします。いくつかの追加のメカニズム（ICEなど）または静的バインディング構成を使用して、IPv6のみのノードへのIPv4のみのノードによって開始された通信をサポートすることができます。
In this section, we describe the different elements involved in the NAT64 approach.
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].
IPv4パケットヘッダーからIPv6パケットヘッダーへのプロトコル変換、およびその逆の翻訳は、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).
アドレス翻訳マップIPv6トランスポースアドレスは、IPv4トランスポートアドレスへのアドレスとその逆です。これらのマッピングを作成するために、NAT64には2つのアドレスプールがあります。IPv6アドレスプール（IPv6ネットワークのIPv4アドレスを表すため）とIPv4アドレスプール（IPv4ネットワークのIPv6アドレスを表す）。
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アドレススペースが豊富であるため、1つ以上のPref64 ::/nを割り当てることができます。それぞれがIPv4アドレススペース全体のサイズに等しいか、さらに大きくなります。これにより、各IPv4アドレスを別のIPv6アドレスにマッピングすることができます。Pref64::/nをマッピングしているIPv4アドレスと接尾辞を単純に連結するだけで。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の通常の練習は、IPv6アドレスがIPv4アドレスを直接導入する代わりに、IPv4輸送アドレスへのIPv6輸送アドレスの結合である可能性が高いため、限られたIPv4アドレスプールのより高い利用を可能にします。これは、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-to-IPV4アドレスマッピングの動的性質とIPv4-to-IPV6アドレスマッピングの静的性質のため、IPv6側からIPv4ノードに向かって開始される通信を可能にする方がはるかに簡単です。IPv4のみのノードからIPv6ノードに開始された通信よりも、IPv6アドレスになります。その場合、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 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.
DNS64などのメカニズムを使用して、IPv6クライアントはIPv4サーバーのIPv4アドレスを埋め込み、そのIPv6アドレスにパケットを送信するIPv6アドレスを取得します。パケットはNAT64デバイスによって傍受されます。NAT64デバイスは、IPv4プールからIPv4輸送アドレスをイニシエーターのIPv6輸送アドレスに関連付けて結合状態を作成し、返信パケットをイニシエーターに転送して転送できるようにします。パケットが流れている間、結合状態は保持されます。フローが停止し、タイマーに基づいて、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 RRSからAAA RRを合成します。合成AAAA RRSに含まれるIPv6アドレスには、NAT64に割り当てられたPref64 ::/nとResponderのIPv4アドレスが含まれています。合成AAAA RRSは、IPv6イニシエーターに渡され、IPv4レシーバーに関連付けられたIPv6アドレスとIPv6通信を開始します。パケットはNAT64デバイスにルーティングされ、以前に説明されているようにIPv6-to-IPV4アドレスマッピングが作成されます。
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のみのサイトに位置し、IPv4ネットワークにあるIPv4のみのノードへのTCP接続を開始するIPv6ノードを検討します。
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).
上の図は、IPv6アドレス2001を備えたIPv6ノードH1：DB8 :: 1とIPv4アドレス192.0.2.1のIPv4ノードH2を示しています。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は、IPv6ネットワークをIPv4ネットワークに接続します。このNAT64は、[RFC6052]で定義されたよく知られている接頭辞64：FF9B ::/96を使用して、IPv6アドレス空間のIPv4アドレスとIPv4インターフェイスに割り当てられた単一のIPv4アドレス203.0.113.1を表します。ルーティングは、64：FF9B ::/96で宛先アドレスにアドレス指定されたIPv6パケットがNAT64デバイスのIPv6インターフェイスにルーティングされるように構成されています。
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機能を備えたローカルネームサーバーも示されています。ローカルネームサーバーは、よく知られているプレフィックス64：FF9B ::/96を使用して、合成RRSでIPv6アドレスを作成します。
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はTCP synパケットをH2に送信します。パケットは、（2001：db8 :: 1,1500）のソース輸送アドレスから（64：ff9b :: 192.0.2.1,80）の宛先輸送アドレスに送信されます。ここで、ポートはH1によって設定されます。
3. The packet is routed to the IPv6 interface of the NAT64 (since IPv6 routing is configured that way).
3. パケットは、NAT64のIPv6インターフェイスにルーティングされます（IPv6ルーティングがその方法で構成されるため）。
4. The NAT64 receives the packet and performs the following actions:
4. NAT64はパケットを受信し、次のアクションを実行します。
* 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)
* NAT64は、IPv4アドレス203.0.113.1で未使用のポート（例えば2000）を選択し、マッピングエントリ（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]を使用して、IPv6ヘッダーをIPv4ヘッダーに変換します。
* 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ノードは、TCP Syn ACKパケットを宛先輸送アドレス（203.0.113.1,2000）およびソーストランスポートアドレス（192.0.2.1,80）で送信することにより応答します。
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インターフェイスに割り当てられているため、パケットはNAT64デバイスにルーティングされ、既存のマッピング（203.0.113.1,2000）を探します。マッピング（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].
* NAT64は、IP/ICMP翻訳アルゴリズム[RFC6145]を使用して、IPv4ヘッダーをIPv6ヘッダーに変換します。
* 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）、パケットのソース輸送アドレスとして（64：ff9b :: 192.0.2.1,80）が含まれます。192.0.2.1は、翻訳されている受信したIPv4パケットのソースIPv4アドレスから直接抽出されることに注意してください。翻訳されたパケットのソースポート80は、受信したIPv4パケットのソースポートと同じです。
8. The translated packet is sent out of the IPv6 interface to H1.
8. 翻訳されたパケットは、IPv6インターフェイスからH1に送信されます。
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.
IPv6イニシエーターH1が、DNSルックアップ以外のスキームを通じてH2のIPv4アドレス（つまり、64：FF9B :: 192.0.2.1）のIPv6表現を学習する場合、翻訳がまだ機能することに注意することが重要です。これは、DNS64処理がNAT64にどの状態がインストールされていないため、IPv4アドレスをIPv6アドレスにマッピングすることが、よく知られているプレフィックスを元の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パケットのエンドポイント非依存フィルタリングを実行すると、着信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パケットのアドレス依存フィルタリングを実行すると、IPv4着信パケットの宛先輸送アドレスと着信IPv4パケットの特定のソースIPアドレスを含む状態がNAT64がない限り、着信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クエリセッションを一意に識別します。ICMPクエリセッションがNAT64を介して流れると、各セッションには2つの異なる3タプルがあります。1つはIPv4アドレスとIPv6アドレスを備えています。
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セッションを一意に識別します。UDP/TCPセッションがNAT64を介して流れると、各セッションには2つの異なる5タプルがあります。1つはIPv4アドレスとIPv6アドレスを備えています。
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.
ビブ：バインディング情報ベース。NAT64が保持しているバインディングの表。各NAT64には、翻訳された各プロトコルにBIBがあります。このドキュメントに準拠した実装には、TCPのBIB、UDP用のBIB、ICMPクエリ用のBIBがあります。SCTPなどの他のプロトコルをサポートするために、追加のBIBが追加されます。
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-to-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-to-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が使用したポートとは独立して）Xにパケットを送信していない場合に状態を持つトランスポートアドレス用に運命づけられます。つまり、特定のIPv4エンドポイントからパケットを受信するには、IPv6エンドポイントが最初に特定のIPv4エンドポイントのIPアドレスにパケットを送信する必要があります。
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].
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パケット。ICMPv6の場合、ICMPV6クエリメッセージは[RFC443]で定義されている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.
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.
セッション：2つの異なるホスト間のパケットのフロー。これは、TCP、UDP、またはICMPクエリです。NAT64では、通常、1つのホストはIPv4ホストであり、もう1つは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つのセッションテーブルがあります。1つはTCP用、もう1つはUDP用、もう1つはICMPクエリ用です。
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.
Stateful Nat64：IPv6パケットをIPv4パケットに変換し、その逆のTCP、UDP、およびICMPの逆に変換する関数。NAT64は、結合状態を使用して、IPv6とIPv4アドレスの間の翻訳を実行します。このドキュメントでは、Stateful 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関数が実行されるデバイス。このドキュメントでは、Stateful 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).
トランスポートアドレス：IPv6またはIPv4アドレスとポートの組み合わせ。通常、（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デバイスには、fref64 :: /nと表示された、それに割り当てられた少なくとも1つのユニキャスト /n IPv6プレフィックスが必要です。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処理に必要な情報が含まれています。NAT64の動作の説明を容易にするために、情報の実際の情報を6つのテーブルに分割することが行われます。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アドレスです。Prime（ '）を備えた大文字はIPv6アドレスです。小文字はポートです。長さnのIPv6プレフィックスは、「p ::/n」で示されています。マッピングは「（x、x）< - >（y '、y）」として示されています。
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:
NAT64には、3つのバインディング情報ベース（BIB）があります。1つはTCP用、1つはUDP用、もう1つはICMPクエリ用です。UDPおよびTCP BIBSの場合、各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アドレスの1つです。BIBには2つの列があります。BIBIPv6輸送アドレスとBIB IPv4輸送アドレスです。特定のIPv6またはIPv4トランスポートアドレスは、BIBの最大1つのエントリに表示されます。たとえば、（2001：DB8 :: 17、49832）は、最大1つのTCPに、最大1つのUDP BIBエントリに表示されます。TCPとUDPのポート番号スペースが異なるため、TCPとUDPには個別のよだれかけがあります。BIBがこのドキュメントで指定されているように実装されている場合、NAT64のエンドポイント非依存マッピングが発生します。BIBSの情報は、エンドポイントに依存しないフィルタリングを実装するためにも使用されます。（アドレス依存フィルタリングは、以下に説明するセッションテーブルを使用して実装されます。）
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アドレスの1つです。指定された（IPv6またはIPv4アドレス、ICMPV6またはICMPV4識別子）ペアは、ICMPクエリBIBの最大1エントリに表示できます。
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つのBIBのいずれかのエントリを動的に作成できますが、管理者が手動で作成することもできます。NAT64実装は、3つのBIBのいずれかの手動で構成された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:
NAT64には3つのセッションテーブルもあります。1つはTCPセッション用、1つはUDPセッション用、もう1つはICMPクエリセッション用です。各エントリは、対応するセッションの状態に関する情報を保持します。TCPおよびUDPセッションテーブルでは、各エントリは、IPv6トランスポートアドレスのペアとIPv4トランスポートアドレスのペア間のマッピングを指定します。
(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アドレスの1つです。y 'は常にIPv4アドレスzのIPv6表現であるため、y'はzから取得され、nat64によって適用されたアルゴリズムを使用してIPv4アドレスのIPv6表現を作成します。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カラムに使用される用語は、着信するIPv6パケットが発信IPv4パケットに変換されるという観点からです。列は次のとおりです。
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 Lifetime。
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ソースアドレスの3タプル、IPv6宛先アドレス、ICMPv6識別子、IPv4ソースアドレス、IPv4宛先アドレス、およびICMPV4識別子の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アドレスの1つです。y 'は常にIPv4アドレスzのIPv6表現であるため、y'はzから取得され、nat64によって適用されたアルゴリズムを使用してIPv4アドレスのIPv6表現を作成します。
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上記の例のz。
The STE ICMPv4 Identifier; i2 in the example above.
STE ICMPV4識別子;上記の例のI2。
The STE lifetime.
Ste Lifetime。
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.
各TCPまたはUDPセッションには、ソースIPv6輸送アドレス（IPv6-> IPv4方向）または宛先IPv4輸送アドレス（IPv4-> IPv6方向）のいずれかによって一意に指定された対応するBIBエントリがあります。各ICMPクエリセッションには、ソースIPv6アドレスとICMPv6識別子（IPv6-> IPv4方向）または宛先IPv4アドレスとICMPv4識別子（IPv4->）のいずれかで一意に指定された対応するBIBエントリがあります。IPv6方向）。ただし、すべてのBIBの場合、単一の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パケットの処理は、次の手順を実行します。
1. Determining the incoming tuple
1. 入ってくるタプルの決定
2. Filtering and updating binding and session information
2. バインディング情報とセッション情報のフィルタリングと更新
3. Computing the outgoing tuple
3. 発信タプルを計算します
4. Translating the packet
4. パケットの翻訳
5. Handling hairpinning
5. ヘアピニングの処理
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エラーパケットの場合、Tupleはソース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クエリメッセージ（つまり、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エラーメッセージが含まれている場合、ICMPエラーメッセージ内に埋め込まれたIPパケットから適切なフィールドを抽出することにより、着信5タプルが計算されます。ただし、これを行うと、ソースと宛先の役割が交換されます。埋め込まれたソースIPアドレスは、着信5タプルの宛先IPアドレスになります。着信5タプルを決定することはできません（おそらく、埋め込みパケットがICMPメッセージ内に再現されていないため）、着信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エラーメッセージが含まれている場合、ICMPエラーメッセージ内に埋め込まれたIPパケットから適切なフィールドを抽出することにより、着信3タプルが計算されます。ただし、これを行うと、ソースと宛先の役割が交換されます。埋め込まれたソースIPアドレスは、着信3タプルの宛先IPアドレスになり、埋め込まれた宛先IPアドレスが着信3タプルのソースアドレスになり、埋め込みのソースアドレスになります。ICMP識別子は、着信3タプルのICMP識別子として使用されます。着信3タプルを決定できない場合（おそらく、埋め込みパケットがICMPメッセージ内に複製されていないため）、着信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は到着時にフラグメントをキューにし、すべてのフラグメントを同時に翻訳することを選択することができます。この場合、入ってくるタプルは、上記のように、フラグメントされていないパケットに記載されているように決定されます。あるいは、NAT64は、最初のフラグメント以外のフラグメントの5タプルを計算できる情報を保存することにより、到着時にフラグメントを翻訳する場合があります。後者の場合、後続のフラグメントが最初の断片の前に到着する可能性があり、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].
UDPパケットをゼロチェックサムで運ぶIPv4パケットを着信する場合、NAT64に十分なリソースがある場合、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エラーメッセージの場合、それらはBIBSまたはセッションテーブルのいずれにも影響を与えないため、このセクションのこれらのメッセージから生じる処理はありません。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は、fref64 ::/nを含むソースアドレスを含むすべての着信IPv6パケットを静かに廃棄する必要があります。これは、セクション5で説明されているようにヘアピニングループを防ぐために必要です。さらに、NAT64は、fref64 ::/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)
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.
Lifetime：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トランスポートアドレスは、対応するUDP BIBエントリから抽出されます。つまり、（t、t）に設定されています。
* 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トランスポートは（Z（Y '）、Y）に設定され、YはSTETENTINEST IPv6 Transportアドレスと同じポートであり、IPv6宛先アドレス（すなわちY'）からアルゴリズム的に生成されるZ（Y '）がZ（Y'）に設定されています。逆アルゴリズムの使用（セクション3.5.4を参照）。
The result is a Session Table Entry as follows:
(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）、つまり着信パケットの宛先IPv4輸送アドレスに等しい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輸送アドレスは（y '（w）、w）に設定され、wはソースIPv4輸送アドレスと同じポートwであり、y'（w）はwのIPv6表現であり、セクション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:
（s '、s）のソーストランスポートアドレス用に新しいUDP BIBエントリが作成されると、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.
s 'をIPv6アドレスとして含む他のBIBエントリが存在し、それをいくつかのIPv4アドレスTにマッピングする場合、NAT64は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. (This behavior is recommended in REQ 3-a of [RFC4787].)
ポートSがよく知られているポート範囲0-1023にあり、NAT64が同じポート範囲で利用可能なポートTを持っている場合、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].)
ポートSが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の別のエントリで使用してはなりませんが、他のBIB（UDPおよびTCP BIBなど）で使用できます。
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ビブとセッションテーブルがどのように埋め込まれているかについて説明します。NAT64がTCPに使用する状態マシンを定義することにより、そうします。最初に州とそれらに含まれる情報について説明し、次に実際の状態マシンと状態の移行について説明します。
The following state information is stored for a TCP session:
次の状態情報は、TCPセッションのために保存されます。
Binding:(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セッションの不活動寿命は少なくとも2時間4分（[RFC5382]に従って）に設定されているため、各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.
閉鎖：[RFC0793]と同様に、閉鎖は架空の状態です。これは、この特定の5タプルの状態がないため、つながりがない場合に状態を表すためです。
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パケットがNAT64によって受信され、IPv4側からTCP接続が開始されていることを意味します。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によって受信、翻訳、転送されました。これは、IPv6側からTCP接続が開始されていることを意味します。NAT64は、TCP synを反対方向に含む一致するIPv4パケットを待っています。
ESTABLISHED: Represents an open connection, with data able to flow in both directions.
確立：オープン接続を表し、データが両方向に流れることができます。
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.
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.
トランス：接続の状態の寿命は、TCP RSTを含むパケットがこの接続のためにNAT64によって受信されたか、単に接続の寿命が減少し、TCP_TRANS分が残っているため、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セグメントを処理します。TCP接続ごとに1つの状態マシンがあり、潜在的にNAT64を通じて確立されています。NAT64デバイスのブートストラップ後、すべてのTCPセッションはクローズド状態にあります。上記で言及したように、閉じた状態は、NAT64にその特定の接続の状態がない場合の架空の状態です。接続ごとに1つの状態マシンがあるため、特定の接続に属するパケットのみが、その接続に関連付けられた状態マシンへの入力であることに注意する必要があります。言い換えれば、以下の状態マシンでパケットが受信されると述べている場合、データパケットの5タプルがステートマシンの1つに一致することが暗黙的です。
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セグメントは、V6 Syn、V4 Syn、V4 Fin、V6 Fin、V6 Fin V4 Fin、V6 RST、およびV4 RSTと呼ばれます。
The figure presents a simplified version of the state machine; refer to the text for the full specification of the state machine.
この図は、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.
そのようなエントリが存在しない場合、NAT64は新しいBIBエントリを作成しようとします（リソースとポリシー許可の場合）。BIB IPv6輸送アドレスは、（x '、x）、つまりパケットのソースIPv6輸送アドレスに設定されています。BIB IPv4輸送アドレスは、セクション3.5.2.3で定義されたルールを使用して割り当てられたIPv4トランスポートアドレスに設定されます。パケットの処理は、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.
STEソースIPv6輸送アドレスは、（x '、x）に設定されています。つまり、受信したV6 synパケットに含まれるソーストランスポートアドレスです。
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セッションテーブルエントリの寿命は、[RFC5382]で定義されているように、少なくともTCP_TRANS（Transitory Connection Idle Timeout）に設定されています。
3. The state of the session is moved to V6 INIT.
3. セッションの状態はV6 initに移動されます。
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接続の場合です）、処理はISです次のように：
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ビブで使用されていない場合、次のとおりです。
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輸送アドレスは、（Y、Y）、つまりV4 Synに含まれるソーストランスポートアドレスに設定されています。
+ 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 Transport 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のIPv6表現（つまり、STE宛先IPv4輸送アドレスのIPv4アドレス）が含まれています。セクション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ビブで使用されている場合、次のとおりです。
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輸送アドレスは、（Y、Y）、つまりV4 Synに含まれるソーストランスポートアドレスに設定されています。
+ 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のIPv6表現（つまり、STE宛先IPv4輸送アドレスのIPv4アドレス）が含まれています。セクション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 ***
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のソースに送り返され、セッションテーブルエントリが削除され、状態が閉じられます。
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
他のパケットについては、セキュリティポリシーが許可されている場合は、パケットを翻訳して転送する必要があります。状態は変わらないままです。
*** V6 INIT ***
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.
ソースIPv4輸送アドレス（Y、Y）と宛先IPv4輸送アドレス（X、X）を備えた入力タプルを備えたV4 Synが（ACKフラグセットの有無にかかわらず）受信された場合、状態は確立されます。TCPセッションテーブルエントリの寿命は、少なくとも最大セッションの寿命に設定されています。最大セッションの寿命の値は構成可能である場合がありますが、tcp_est（[rfc5382]で定義されている確立された接続アイドルタイムアウト）以下である必要があります。最大セッションの寿命のデフォルト値は、tcp_estに設定する必要があります。パケットは翻訳され、転送されます。
If the lifetime expires, the Session Table Entry is deleted, and the state is moved to 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は、ピアが状態を閉じる代わりにRSTパケットを受け入れるかどうかは不明であるため、寿命が短いトランスに移動します。短いタイマー中にこの接続に対して他のパケットが受信されない場合、NAT64ピアがRSTパケットを受け入れ、閉じて移動すると仮定します。パケットが流れ続けると、NAT64はピアが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に設定する必要があります。状態は確立されているように変更されていません。
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接続の少なくとも1つのエンドポイントにプローブパケット（次に定義されているように）を送信する必要があります。プローブパケットは、データなしの接続のTCPセグメントです。シーケンス番号と確認番号はゼロに設定されています。ACKフラグ以外のすべてのフラグはゼロに設定されています。状態はトランスに移動されます。
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で応答します。アクティブな接続の場合、これらのプローブパケットのそれぞれは、プローブパケットへの最初のポイントの応答が他のエンドポイントから応答を生成するため、接続に関係する両端から1つのパケットを生成することに注意してください。
*** V4 FIN RCV ***
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.
寿命が切れると、セッションテーブルのエントリが削除され、状態が閉鎖されます。
*** 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フィンRCVとして変化していません。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
寿命が切れると、セッションテーブルのエントリが削除され、状態が閉鎖されます。
*** V6 FIN + V4 FIN RCV ***
All packets are translated and forwarded.
すべてのパケットは翻訳され、転送されます。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
寿命が切れると、セッションテーブルのエントリが削除され、状態が閉鎖されます。
*** 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.
寿命が切れると、セッションテーブルのエントリが削除され、状態が閉鎖されます。
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:
（s '、s）のソーストランスポートアドレス用に新しいTCP BIBエントリが作成されると、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.
S 'をIPv6アドレスとして含むBIBのいずれかに他のBIBエントリが存在し、IPv4アドレスTにマップする場合、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が同じポート範囲で利用可能なポートTを持っている場合、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.
ポートSが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の別のエントリで使用してはなりませんが、他のBIB（UDPおよびTCP BIBなど）で使用できます。
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)
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.
Lifetime：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 'を含むBIBのいずれかに別のBIBエントリが存在し、IPv4アドレスTにマップする場合は、この新しいエントリの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は、IPv4アドレスとしてxを含むICMPクエリBIBエントリ、ICMPV4識別子としてi2を検索します。そのようなエントリが存在しない場合、パケットが削除されます。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アドレスを使用して、SETソースIPv4アドレスを使用してセッションテーブルエントリを検索します。そのようなエントリが見つかった場合（1つより）、パケット処理が続きます。それ以外の場合、パケットは破棄されます。パケットが破棄されている場合、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に等しい、ste icmpv4識別子はi2に等しく、yに等しい宛先IPv4アドレスがyに等しい。そのようなエントリが見つからない場合、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).
アルゴリズムの入力は、IPv4アドレス、IPv6表現で使用されるIPv6プレフィックス（fref64 ::/n）、およびオプションで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].
プレフィックスの長さをnに注意する場合、pref64 ::/n、nは96以下である必要があります。Pref64::/nがNAT64の任意の手段で構成されている場合（手動で構成された、またはその他の自動このドキュメントで指定されていないことを意味します）、デフォルトのアルゴリズムはこのプレフィックスを使用する必要があります。プレフィックスが使用できない場合、アルゴリズムは[RFC6052]で定義されているよく知られているプレフィックス（64：FF9B ::/96）を使用する必要があります。
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宛先輸送アドレスに変換するために使用されます。IPv6宛先輸送アドレスをIPv4宛先輸送アドレスに変換するためにも使用されず、IPv4ソース輸送アドレスをIPv6ソース輸送アドレスに変換することもありません。後者のケースは、セクション3.5.4で説明されているアルゴリズム変換を適用することにより処理されます。この区別は重要です。それがなければ、ヘアピニングは正しく機能しません。
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タプル（s '、s）および（d'、d）のソースと宛先の輸送アドレスをそれぞれにします。発信ソーストランスポートアドレスは次のように計算されます。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).
BIBテーブルはエントリ（x '、x）<->（d、d）を検索し、見つかった場合、発信先の輸送アドレスは（x'、x）に設定されます。
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方向に翻訳する場合、着信3タプルのソースと宛先アドレスをそれぞれs 'およびd'とし、ICMPv6識別子をI1とします。発信ソースアドレスは次のように計算されます。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、i2）を含むエントリを検索し、見つかった場合、発信宛先アドレスは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.
o IPヘッダー（[RFC6145]のセクション4.1および5.1）を翻訳すると、セクション3.6で決定されているように、ソースおよび宛先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].
o IPヘッダーに続くプロトコルがTCPまたはUDPである場合、ソースと宛先ポートは、発信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.
o IPヘッダーに続くプロトコルがICMPであり、ICMPクエリメッセージである場合、ICMP識別子は、セクション3.6.2で決定されたように、発信3タプルからの識別子に設定されます。
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).
o IPヘッダーに続くプロトコルがICMPであり、ICMPエラーメッセージである場合、埋め込まれたパケットのソースおよび宛先輸送アドレスが宛先に設定され、発信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セッションの最低寿命は2時間4分です。これは、このタイマーで2時間、TCP_TRANSタイマーで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検証が失敗することを意味します。これは、ネットワーク層翻訳メカニズムに固有のものです。[RFC3948]で説明されているUDPカプセル化を使用して、エンドツーエンドのIPSEC保護を復元できます。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は、IPv6側からIPv4側に流れるパケットを使用して結合状態を作成します。[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、S1）と宛先（PREF64 :: D1、D1）を備えたIPv6パケットの場合、（s1、s1v4）、（d1、d1）への外部マッピングを作成します。、s1）から（s2、s2v4）、（d2、d2）に外部マッピングを作成する（pref64 :: d2、d2）、特定のバインディングタイマーウィンドウ内で、
(S1,s1v4) = (S2,s2v4) for all values of 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,
フィルタリングなし - 「エンドポイント非依存マッピング」がNAT64で使用される場合、IPv6 ---> IPv4方向にバインディングが作成されると、IPv4輸送アドレスに運命づけられたIPv4側の任意のノードからのパケットがNAT64ゲートウェイを通過し、バインディングを作成したIPv6輸送アドレスに転送します。でも、
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.
フィルタリングの場合 - 「エンドポイント非依存マッピング」がNAT64で使用される場合、IPv6 ---> IPv4方向にバインディングが作成されると、IPv6輸送アドレスに運命づけられたIPv4側のノードからのパケットが最初に処理されます。フィルタリングルール。ソースIPv4アドレスが許可されている場合、パケットはIPv6輸送アドレスに転送されます。ソースIPv4アドレスが明示的に拒否された場合、またはデフォルトのポリシーが明示的に許可されていないすべてのアドレスを拒否することである場合、パケットは破棄されます。ダイナミックフィルターが使用される場合があり、フィルターは、バインディングを作成した元のパケットが送信されたIPv4アドレスからのみパケットを許可します。これは、IPv6ホストが接続を開始したIPv4アドレスのみがIPv6輸送アドレスに到達できるようにすることを意味します。これは本質的に、NAT64デバイスの効果的な動作を「アドレス依存マッピング」動作に絞り込みますが、そのマッピング動作ではなく、そのフィルタリング動作によるものです。
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は、交換されたセグメント、特にSynsとFINSの適切なシーケンスを検証するために、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 Synsの場合、状況は、特定の時間の間データパケットを保存する要件によって悪化し、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でループできます。これは、以下に説明するように、ソースアドレスにfref64 ::/nを含む着信パケットをフィルタリングすることにより、現在の仕様で防止されます。
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
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は、192.0.2.1:500をIPv4バインディングアドレスとして割り当てます。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アドレスを推測するのは難しくありません。まず、攻撃者はバインディングを作成し、（たとえば、NAT（Stun）[RFC5389]を介したUDPプロトコルの単純なトラバーサルを使用して、外部IPv4アドレスを学習します。新しいバインディングには常にこのアドレスがあります。次に、範囲1-1023のソースポートを使用します。これにより、チャンスが1/512に増加します（範囲とパリティはUDPでNAT64によって保存されるため）。
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.
この脆弱性に対処するために、NAT64は、セクション3.5で定義されているように、ソースアドレスがPref64 ::/NにあるIPv6パケットをドロップする必要があります。
George Tsirtsis Qualcomm tsirtsis@googlemail.com
George Tsirtsis qualcomm tsirtsis@googlemail.com
Greg Lebovitz Juniper gregory.ietf@gmail.com
Greg Lebovitz Juniper Gregory.ietf@gmail.com
Simon Perreault Viagenie simon.perreault@viagenie.ca
Simon Perreault 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.
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西部、デビッド・ハリントン、ピーター・マッキャン、ジュリアン・ラガニエ、ペッカ・サヴォラ、ジョア・ダマスは文書をレビューし、それを改善するために有用なコメントを提供しました。
The content of the document was improved thanks to discussions with Christian Huitema, Fred Baker, and Jari 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.
Marcelo BagnuloとIljitsch van Beijnumは、第7回のフレームワークプログラムに基づいて欧州委員会が支援する研究プロジェクトであるTrilogyによって部分的に資金提供されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン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. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT行動要件」、BCP 142、RFC 5382、2008年10月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508] Srisuresh、P.、Ford、B.、Sivakumar、S。、およびS. Guha、「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] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、2010年10月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP/ICMP翻訳アルゴリズム」、RFC 6145、2011年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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.、Reed、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] Miller、I。、「小さなフラグメント攻撃（RFC 1858）のバリアントに対する保護」、RFC 3128、2001年6月。
[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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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.、Mathis、M。、およびB. Chandler、「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] Rosenberg、J。、「Interactive Connectivity Indecivity（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] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「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] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「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.、Sullivan、A.、Matthews、P。、およびI. Van Beijnum、 "DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のDNS拡張"、RFC 6147、2011年4月。
Authors' Addresses
著者のアドレス
Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo UC3M AV。Universidad 30 Leganes、Madrid 28911スペイン
Phone: +34-91-6249500
EMail: 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
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van beijnum imdea Networks avda。Del Mar Mediterraneo、22 Leganes、Madrid 28918スペイン
EMail: iljitsch@muada.com