[要約] RFC 6144は、IPv4とIPv6の翻訳のためのフレームワークを提供するものであり、IPv4とIPv6の相互運用性を向上させることを目的としています。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6144 Cisco Systems
Category: Informational X. Li
ISSN: 2070-1721 C. Bao
CERNET Center/Tsinghua University
K. Yin
Cisco Systems
April 2011
Framework for IPv4/IPv6 Translation
IPv4/IPv6翻訳のフレームワーク
Abstract
概要
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.
このメモは、IPv4/IPv6翻訳のフレームワークについて説明しています。これは、ネットワークアドレス変換-Protocol Translation（NAT -PT）を置き換えるコンテキストであり、RFC 4966によって非難され、IPv6ネットワークに移行しながらNetworkがIPv4とIPv6を幾分合理的に共存できるようにします。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6144.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6144で取得できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7
1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 9
2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 11
2.1. Scenario 1: An IPv6 Network to the IPv4 Internet . . . . . 12
2.2. Scenario 2: The IPv4 Internet to an IPv6 Network . . . . . 13
2.3. Scenario 3: The IPv6 Internet to an IPv4 Network . . . . . 14
2.4. Scenario 4: An IPv4 Network to the IPv6 Internet . . . . . 15
2.5. Scenario 5: An IPv6 Network to an IPv4 Network . . . . . . 16
2.6. Scenario 6: An IPv4 Network to an IPv6 Network . . . . . . 17
2.7. Scenario 7: The IPv6 Internet to the IPv4 Internet . . . . 18
2.8. Scenario 8: The IPv4 Internet to the IPv6 Internet . . . . 19
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Translation Components . . . . . . . . . . . . . . . . . . 19
3.1.1. Address Translation . . . . . . . . . . . . . . . . . 19
3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 21
3.1.3. Maintaining Translation State . . . . . . . . . . . . 21
3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 22
3.1.5. ALGs for Other Applications Layer Protocols . . . . . 22
3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 22
3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 23
3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 24
3.3. Layout of the Related Documents . . . . . . . . . . . . . 26
4. Translation in Operation . . . . . . . . . . . . . . . . . . . 27
5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT (Network Address Translation - Protocol Translation) [RFC2766], which was deprecated by [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6-only network.
このメモは、IPv4/IPv6翻訳のフレームワークについて説明しています。これは、NAT -PT（ネットワークアドレス変換 - プロトコル変換）[RFC2766]を置き換えるコンテキストであり、[RFC4966]によって非推奨され、IPv6とIPv6がIPv6とIPv6を幾分合理的に共存できるようにします。 - ネットワークのみ。
NAT-PT was deprecated to inform the community that NAT-PT had operational issues and was not considered a viable medium- or long-term strategy for either coexistence or transition. It wasn't intended to say that IPv4<->IPv6 translation was bad, but the way that NAT-PT did it was bad, and in particular using NAT-PT as a general-purpose solution was bad. As with the deprecation of the RIP routing protocol [RFC1923] at the time the Internet was converting to Classless Inter-Domain Routing (CIDR), the point was to encourage network operators to actually move away from technology with known issues.
NAT-PTは、NAT-PTが運用上の問題を抱えており、共存または移行のいずれかの実行可能な中期的または長期的な戦略とは見なされていないことをコミュニティに知らせるために非難されました。IPv4 < - > IPv6の翻訳は悪かったと言うことを意図していませんでしたが、NAT-PTのやり方が悪かったのは、特にNAT-PTを汎用ソリューションとして使用することは悪かったのです。RIPルーティングプロトコル[RFC1923]の非推奨と同様に、インターネットがクラスレスインタードメインルーティング（CIDR）に変換されていた時点で、ネットワークオペレーターが既知の問題を抱えたテクノロジーから実際に移動することを奨励することでした。
[RFC4213] describes the IETF's view of the most sensible transition model. The IETF recommends, in short, that network operators (transit providers, service providers, enterprise networks, small and medium businesses, SOHO (Small Office, Home Office) and residential customers, and any other kind of network that may currently be using IPv4) obtain an IPv6 prefix, turn on IPv6 routing within their networks and between themselves and any peer, upstream, or downstream neighbors, enable it on their computers, and use it in normal processing. This should be done while leaving IPv4 stable, until a point is reached that any communication that can be carried out could use either protocol equally well. At that point, the economic justification for running both becomes debatable, and network operators can justifiably turn IPv4 off. This process is comparable to that of [RFC4192], which describes how to renumber a network using the same address family without a flag day. While running stably with the older system, deploy the new. Use the coexistence period to work out such kinks as they arise. When the new is also running stably, shift production to it. When network and economic conditions warrant, remove the old, which is now no longer necessary.
[RFC4213]は、最も賢明な遷移モデルのIETFの見解を説明しています。IETFは、要するに、ネットワークオペレーター（トランジットプロバイダー、サービスプロバイダー、エンタープライズネットワーク、中小企業、SOHO（小オフィス、ホームオフィス）、および住宅顧客、および現在IPv4を使用している可能性のある他の種類のネットワーク）を推奨しています。IPv6プレフィックスを取得し、ネットワーク内および自分自身とピア、アップストリーム、または下流の隣人の間でIPv6ルーティングをオンにし、コンピューターで有効にし、通常の処理で使用します。これは、実行できる通信がいずれかのプロトコルを等しく使用できるとポイントに達するまで、IPv4を安定させたままにする必要があります。その時点で、両方を実行するための経済的正当化は議論の余地があり、ネットワークオペレーターは正当にIPv4をオフにすることができます。このプロセスは、[RFC4192]のプロセスに匹敵します。これは、旗の日なしで同じアドレスファミリを使用してネットワークを変更する方法を説明しています。古いシステムで安定して走っている間、新しいシステムを展開します。共存期間を使用して、そのようなねじれが発生したときに解決します。新しいものも安定して実行されている場合は、生産をシフトします。ネットワークと経済状況が必要な場合は、古いものを削除します。これはもはや必要ありません。
The question arises: what if that is infeasible due to the time available to deploy or other considerations? What if the process of moving a network and its components or customers is starting too late for contract cycles to effect IPv6 turn-up on important parts at a point where it becomes uneconomical to deploy global IPv4 addresses in new services? How does one continue to deploy new services without balkanizing the network? This document describes translation as one of the tools networks might use to facilitate coexistence and ultimate transition.
疑問が生じます：展開できる時間やその他の考慮事項のためにそれが実行不可能な場合はどうなりますか？ネットワークとそのコンポーネントまたは顧客を移動するプロセスが、契約サイクルが新しいサービスにグローバルIPv4アドレスを展開することが非経済的になるポイントで重要な部品にIPv6ターンアップを行うには遅すぎる場合はどうなりますか？ネットワークをバルカン化せずに、どのようにして新しいサービスを展開し続けますか？このドキュメントは、翻訳を、ネットワークが共存と最終的な移行を促進するために使用できるツールの1つとして説明しています。
Besides dual-stack deployment, there are two fundamental approaches one could take to interworking between IPv4 and IPv6: tunneling and translation. One could -- and in the [6NET] we did -- build an overlay network that tunnels one protocol over the other. Various proposals take that model, including 6to4 [RFC3056], Teredo [RFC4380], Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and Dual-Stack Lite [DS-LITE]. The advantage of doing so is that the new protocol is enabled to work without disturbing the old protocol, providing connectivity between users of the new protocol. There are two disadvantages to tunneling:
デュアルスタックの展開に加えて、IPv4とIPv6の間でトンネリングと翻訳をインターワーキングするために得られる2つの基本的なアプローチがあります。一方は、[6NET]では、一方のプロトコルを他方のプロトコルにトンネルするオーバーレイネットワークを構築できます。6to4 [RFC3056]、Teredo [RFC4380]、敷地内自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214]、およびデュアルスタックライト[DS-Lite]など、さまざまな提案がそのモデルを取ります。そうすることの利点は、新しいプロトコルを乱すことなく新しいプロトコルが機能し、新しいプロトコルのユーザー間の接続性を提供することです。トンネリングには2つの欠点があります。
o Users of the new architecture are unable to use the services of the underlying infrastructure -- it is just bandwidth, and
o 新しいアーキテクチャのユーザーは、基礎となるインフラストラクチャのサービスを使用することができません - それはただの帯域幅であり、
o It doesn't enable new protocol users to communicate with old protocol users without dual-stack hosts.
o 新しいプロトコルユーザーは、デュアルスタックホストなしで古いプロトコルユーザーと通信することはできません。
As noted, in this work, we look at Internet Protocol translation as a transition strategy. [RFC4864] forcefully makes the point that people use Network Address Translators to meet various needs, many of which are met as well by routing or protocol mechanisms that preserve the end-to-end addressability of the Internet. What it did not consider is the case in which there is an ongoing requirement to communicate with IPv4 systems, but, for example, configuring IPv4 routing is not the most desirable strategy in the network operator's view, or is infeasible due to a shortage of global address space. Translation enables the client of a network, whether a transit network, an access network, or an edge network, to access the services of the network and communicate with other network users regardless of their protocol usage -- within limits. Like NAT-PT, IPv4/IPv6 translation under this rubric is not a long-term support strategy, but it is a medium-term coexistence strategy that can be used to facilitate a long-term program of transition.
前述のように、この作業では、インターネットプロトコルの翻訳を移行戦略として検討します。[RFC4864]は、人々がネットワークアドレス翻訳者を使用してさまざまなニーズを満たすことを強制的に述べています。その多くは、インターネットのエンドツーエンドのアドレス指定を維持するルーティングまたはプロトコルメカニズムによって満たされます。考慮していなかったのは、IPv4システムと通信するための継続的な要件がある場合ですが、たとえば、IPv4ルーティングの構成は、ネットワークオペレーターの見解で最も望ましい戦略ではないか、グローバルなグローバルの不足のために実行不可能です住所スペース。翻訳により、トランジットネットワーク、アクセスネットワーク、エッジネットワークなど、ネットワークのクライアントがネットワークのサービスにアクセスし、プロトコルの使用に関係なく他のネットワークユーザーと通信できます。NAT-PTと同様に、このルーブリックの下でのIPv4/IPv6翻訳は長期的なサポート戦略ではありませんが、長期的な移行プログラムを促進するために使用できる中期的な共存戦略です。
The following terminology is used in this document and other documents related to it.
次の用語は、このドキュメントとそれに関連するその他のドキュメントで使用されています。
An IPv4 network: A specific network that has an IPv4-only deployment. This could be an enterprise's IPv4-only network, an ISP's IPv4-only network, or even an IPv4-only host. The IPv4 Internet is the set of all interconnected IPv4 networks.
IPv4ネットワーク：IPv4のみの展開を備えた特定のネットワーク。これは、EnterpriseのIPv4のみのネットワーク、ISPのIPv4のみのネットワーク、またはIPv4のみのホストでもあります。IPv4インターネットは、相互接続されたすべてのIPv4ネットワークのセットです。
An IPv6 network: A specific network that has an IPv6-only deployment. This could be an enterprise's IPv6-only network, an ISP's IPv6-only network, or even an IPv6-only host. The IPv6 Internet is the set of all interconnected IPv6 networks.
IPv6ネットワーク：IPv6のみの展開を備えた特定のネットワーク。これは、EnterpriseのIPv6のみのネットワーク、ISPのIPv6のみのネットワーク、またはIPv6のみのホストでもあります。IPv6インターネットは、相互接続されたすべてのIPv6ネットワークのセットです。
DNS46: A DNS translator that translates AAAA record to A record.
DNS46：AAAAレコードをレコードに翻訳するDNS翻訳者。
DNS64: A DNS translator that translates A record to AAAA record.
DNS64：レコードをAAAAレコードに翻訳するDNS翻訳者。
Dual-Stack implementation: A dual-stack implementation, in this context, comprises an IPv4/IPv6-enabled end system stack, applications plus routing in the network. It implies that two application instances are capable of communicating using either IPv4 or IPv6 -- they have stacks, they have addresses, and they have any necessary network support including routing.
デュアルスタックの実装：このコンテキストでは、デュアルスタックの実装は、IPv4/IPv6対応のエンドシステムスタック、アプリケーションとネットワーク内のルーティングを含む。これは、2つのアプリケーションインスタンスがIPv4またはIPv6のいずれかを使用して通信できることを意味します。スタックがあり、アドレスがあり、ルーティングを含む必要なネットワークサポートがあります。
IPv4-converted addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They have an explicit mapping relationship to IPv4 addresses. Both stateless and stateful translators use IPv4-converted addresses to represent IPv4 addresses.
IPv4コンバージドアドレス：IPv6ネットワーク内のIPv4ノードを表すために使用されるIPv6アドレス。IPv4アドレスと明示的なマッピング関係があります。StatelessとStatefulの両方の翻訳者はどちらもIPv4コンセントアドレスを使用してIPv4アドレスを表します。
IPv4-only: An IPv4-only implementation, in this context, comprises an IPv4-enabled end system stack, applications directly or indirectly using that IPv4 stack, plus routing in the network. It implies that two application instances are capable of communicating using IPv4, but not IPv6 -- they have an IPv4 stack, addresses, and network support including IPv4 routing and potentially IPv4/IPv4 translation, but some element is missing that prevents communication with IPv6 hosts.
IPv4のみ：IPv4のみの実装は、このコンテキストでは、IPv4対応のENDシステムスタック、そのIPv4スタックを直接または間接的に使用してアプリケーションを使用して、ネットワーク内のルーティングを含む。IPv4ではなくIPv4を使用して通信できる2つのアプリケーションインスタンスは、IPv4スタック、アドレス、およびIPv4/IPv4翻訳を含むネットワークサポートを備えていることを意味しますが、IPv6ホストとの通信を防止する要素は欠落しています。。
IPv4-translatable addresses: IPv6 addresses to be assigned to IPv6 nodes for use with stateless translation. They have an explicit mapping relationship to IPv4 addresses. A stateless translator uses the corresponding IPv4 addresses to represent the IPv6 addresses. A stateful translator does not use this kind of addresses, since IPv6 hosts are represented by the IPv4 address pool in the translator via dynamic state.
IPv4翻訳可能なアドレス：IPv6アドレスは、Stateless Translationで使用するためにIPv6ノードに割り当てられます。IPv4アドレスと明示的なマッピング関係があります。Stateless Translatorは、対応するIPv4アドレスを使用してIPv6アドレスを表します。IPv6ホストは動的状態を介して翻訳者のIPv4アドレスプールで表されるため、ステートフルな翻訳者はこの種のアドレスを使用しません。
IPv6-only: An IPv6-only implementation, in this context, comprises an IPv6-enabled end system stack, applications directly or indirectly using that IPv6 stack, plus routing in the network. It implies that two application instances are capable of communicating using IPv6, but not IPv4 -- they have an IPv6 stack, addresses, and network support including routing in IPv6, but some element is missing that prevents communication with IPv4 hosts.
IPv6のみ：IPv6のみの実装は、このコンテキストでは、IPv6対応のエンドシステムスタック、そのIPv6スタックを直接または間接的にアプリケーションを使用して、ネットワーク内のルーティングを使用します。IPv6ではなくIPv6を使用して通信できる2つのアプリケーションインスタンスがIPv6スタック、アドレス、およびIPv6のルーティングを含むネットワークサポートを持っていることを意味しますが、IPv4ホストとの通信を防ぐ要素は欠落しています。
Network-Specific Prefix (NSP): From an IPv6 prefix assigned to a network operator, the operator chooses a longer prefix for use by the operator's translator(s). Hence, a given IPv4 address would have different IPv6 representations in different networks that use different network-specific prefixes. A network-specific prefix is also known as a Local Internet Registry (LIR) prefix.
ネットワーク固有のプレフィックス（NSP）：ネットワークオペレーターに割り当てられたIPv6プレフィックスから、オペレーターはオペレーターの翻訳者が使用するためのより長いプレフィックスを選択します。したがって、特定のIPv4アドレスは、異なるネットワーク固有のプレフィックスを使用する異なるネットワークで異なるIPv6表現を持っています。ネットワーク固有のプレフィックスは、ローカルインターネットレジストリ（LIR）プレフィックスとも呼ばれます。
State: "State" refers to dynamic information that is stored in a network element. For example, if two systems are communicating using a TCP connection, each stores information about the connection, which is called "connection state". In this context, the term refers to dynamic correlations between IP addresses on either side of a translator, or {IP address, transport protocol, transport port number} tuples on either side of the translator. Of stateful algorithms, there are at least two major flavors depending on the kind of state they maintain:
状態：「状態」とは、ネットワーク要素に保存されている動的な情報を指します。たとえば、2つのシステムがTCP接続を使用して通信している場合、各システムは「接続状態」と呼ばれる接続に関する情報を保存します。これに関連して、この用語は、翻訳者の両側のIPアドレス間の動的相関、または{IPアドレス、トランスポートプロトコル、トランスポートポート番号}翻訳者の両側のタプルの動的相関を指します。ステートフルアルゴリズムのうち、彼らが維持する状態の種類に応じて、少なくとも2つの主要なフレーバーがあります。
Hidden state: the existence of this state is unknown outside the network element that contains it.
隠された状態：この状態の存在は、それを含むネットワーク要素の外側に不明です。
Known state: the existence of this state is known by other network elements.
既知の状態：この状態の存在は、他のネットワーク要素によって知られています。
Stateful Translation: A translation algorithm may be said to "require state in a network element" or be "stateful" if the transmission or reception of a packet creates or modifies a data structure in the relevant network element.
ステートフルな翻訳：翻訳アルゴリズムは、パケットの送信または受信が関連するネットワーク要素にデータ構造を作成または変更する場合、「ネットワーク要素の状態を必要とする」または「ステートフル」になると言えます。
Stateful Translator: A translator that uses stateful translation for either the source or destination address. A stateful translator typically also uses a stateless translation algorithm for the other type of address.
ステートフル翻訳者：ソースまたは宛先アドレスのいずれかにステートフルな翻訳を使用する翻訳者。ステートフルな翻訳者は、通常、他のタイプのアドレスにステートレス翻訳アルゴリズムも使用します。
Stateless Translation: A translation algorithm that is not "stateful" is "stateless". It derives its needed information algorithmically from the messages it is translating and from pre-configured information.
ステートレス翻訳：「ステートフル」ではない翻訳アルゴリズムは「ステートレス」です。翻訳しているメッセージと事前に構成された情報から、必要な情報をアルゴリズム的に導き出します。
Stateless Translator: A translator that uses only stateless translation for both destination address and source address.
ステートレス翻訳者：宛先アドレスとソースアドレスの両方に無国籍翻訳のみを使用する翻訳者。
Well-Known Prefix (WKP): The IPv6 prefix defined in [RFC6052] for use in an algorithmic mapping.
よく知られているプレフィックス（WKP）：アルゴリズムマッピングで使用するための[RFC6052]で定義されたIPv6プレフィックス。
In any translation model, there is a question of objectives. Ideally, one would like to make any system and any application running on it able to "talk with" -- exchange datagrams supporting applications with -- any other system running the same application regardless of whether they have an IPv4 stack and connectivity or IPv6 stack and connectivity. That was the model for NAT-PT, and the things it necessitated led to scaling and operational difficulties [RFC4966].
翻訳モデルには、目的の問題があります。理想的には、IPv4スタックと接続性またはIPv6スタックを持っているかどうかに関係なく、同じアプリケーションを実行している他のシステムをサポートするデータグラムを「通話」することができるシステムとそのアプリケーションを実行できるアプリケーションを作成したいと考えています。および接続。それがNAT-PTのモデルであり、それが必要としたものはスケーリングと運用上の困難をもたらしました[RFC4966]。
So the question comes back to what different kinds of connectivity can be easily supported, what kinds are harder, and what technologies are needed to at least pick the low-hanging fruit. We observe that applications today fall into two main categories:
したがって、問題は、どのような種類の接続性を簡単にサポートできるか、どのような種類がより困難で、少なくとも垂れ下がった果物を選ぶために必要な技術が必要ですか。今日のアプリケーションは、2つの主要なカテゴリに分類されることがわかります。
Client/Server Application: Per whatis.com, "'Client/server' describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request." In networking, the behavior of the applications is that connections are initiated from client software and systems to server software and systems. Examples include mail handling between an end user and his mail system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name resolution.
クライアント/サーバーアプリケーション：whatis.comに従って、「 'client/server」は、1つのプログラムであるクライアントが別のプログラム、リクエストを満たすサーバーからサービスリクエストを行う2つのコンピュータープログラム間の関係を説明します。」ネットワーキングでは、アプリケーションの動作は、クライアントソフトウェアとシステムからサーバーソフトウェアとシステムに接続が開始されることです。例には、エンドユーザーと彼のメールシステム間のメール処理（POP3、IMAP、およびMUA-> MTA SMTP）、FTP、Web、およびDNS名の解像度が含まれます。
Peer-to-Peer (P2P) Application: A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. These in turn fall broadly into two categories:
ピアツーピア（P2P）アプリケーション：P2Pアプリケーションは、同じエンドポイントを使用して、ピアリングホストへの発信セッションを開始し、ピアリングホストからの着信セッションを受け入れるアプリケーションです。これらは、次の2つのカテゴリに大きく分類されます。
Peer-to-peer infrastructure applications: Examples of "infrastructure applications" include SMTP between MTAs, Network News, and SIP. Any MTA might open an SMTP session with any other at any time; any SIP Proxy might similarly connect with any other SIP Proxy. An important characteristic of these applications is that they use ephemeral sessions -- they open sessions when they are needed and close them when they are done.
ピアツーピアインフラストラクチャアプリケーション：「インフラストラクチャアプリケーション」の例には、MTA、ネットワークニュース、SIP間のSMTPが含まれます。MTAは、いつでも他の人とSMTPセッションを開く可能性があります。SIPプロキシは、同様に他のSIPプロキシと接続する場合があります。これらのアプリケーションの重要な特徴は、彼らが短命セッションを使用することです - 彼らは必要なときにセッションを開き、それらが完了したときにそれらを閉じます。
Peer-to-peer file exchange applications: Examples of these include Limewire, BitTorrent, and UTorrent. These are applications that open some sessions between systems and leave them open for long periods of time, and where ephemeral sessions are important, these applications are able to learn about the reliability of peers from history or by reputation. They use the long-term sessions to map content availability.
ピアツーピアファイル交換アプリケーション：これらの例には、Limewire、Bittorrent、およびUtorrentが含まれます。これらは、システム間でいくつかのセッションを開き、それらを長時間開いたままにしておくアプリケーションであり、はかないセッションが重要な場合、これらのアプリケーションは歴史や評判によるピアの信頼性について学ぶことができます。長期セッションを使用して、コンテンツの可用性をマッピングします。
Short-term sessions are used to exchange content. They tend to prefer to ask for content from peers that they find reliable and available.
短期セッションは、コンテンツを交換するために使用されます。彼らは、信頼性が高く利用可能だと思う仲間からコンテンツを求めることを好む傾向があります。
If the goal is the ability to open connections between systems, then one must ask who opens connections.
目標がシステム間で接続を開く機能である場合、誰が接続を開くかを尋ねる必要があります。
o We need a technology that will enable systems that act as clients to be able to open sessions with other systems that act as servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Ideally, this is stateless; especially in a carrier infrastructure, the preponderance of accesses will be to servers, and this optimizes access to them. However, a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed.
o クライアントとして機能するシステムが、IPv6-> IPv4方向であろうとIPv4-> IPv6方向であろうと、サーバーとして機能する他のシステムとセッションを開くことができるようにするテクノロジーが必要です。理想的には、これは無国籍です。特にキャリアインフラストラクチャでは、アクセスの優勢はサーバーになり、これによりアクセスが最適化されます。ただし、複雑さを最小限に抑え、ステートレスアルゴリズムを構築できない場合、ステートフルアルゴリズムは許容されます。
o We also need a technology that will allow peers to connect with each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Again, it would be ideal if this was stateless, but a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed.
o また、IPv6-> IPv4方向であろうとIPv4-> IPv6方向であろうと、ピアが互いに接続できるようにするテクノロジーも必要です。繰り返しますが、これがステートレスである場合は理想的ですが、複雑さを最小限に抑え、ステートレスアルゴリズムを構築できない場合、ステートフルアルゴリズムは受け入れられます。
o In some situations, hosts are purely clients. In those situations, we do not need an algorithm to enable connections to those hosts.
o 状況によっては、ホストは純粋にクライアントです。これらの状況では、それらのホストへの接続を有効にするためのアルゴリズムは必要ありません。
The complexity arguments bring us in the direction of hidden state: if state must be shared between the application and the translator or between translation components, complexity and deployment issues are greatly magnified. The objective of the translators is to avoid, as much as possible, any software changes in hosts or applications necessary to support translation.
複雑さの議論は、隠された状態の方向に私たちをもたらします。アプリケーションと翻訳者の間、または翻訳コンポーネントの間で状態を共有する必要がある場合、複雑さと展開の問題が大幅に拡大されます。翻訳者の目的は、翻訳をサポートするために必要なホストまたはアプリケーションのソフトウェアの変更を可能な限り回避することです。
NAT-PT is an example of a facility with known state -- at least two software components (the data-plane translator and the DNS Application Layer Gateway, which may be implemented in the same or different systems) share and must coordinate translation state. A typical IPv4/IPv4 NAT implements an algorithm with hidden state. Obviously, stateless translation requires less computational overhead than stateful translation, and less memory to maintain the state, because the translation tables and their associated methods and processes exist in a stateful algorithm and don't exist in a stateless one.
NAT-PTは、既知の状態（少なくとも2つのソフトウェアコンポーネント（データプレーン翻訳者とDNSアプリケーションレイヤーゲートウェイ）が同じまたは異なるシステムで実装される可能性がある）を持つ施設の例であり、翻訳状態を調整する必要があります。典型的なIPv4/IPv4 NATは、非表示状態のアルゴリズムを実装します。明らかに、ステートレスの翻訳は、ステートフルな翻訳よりも計算上のオーバーヘッドが少なく、状態を維持するためのメモリが少なくなります。これは、翻訳テーブルとそれに関連する方法とプロセスがステートフルなアルゴリズムに存在し、ステートレスのものには存在しないためです。
While the design of IPv4 made it impossible for IPv6 to be compatible on the wire, the designers intended that it would coexist with IPv4 during a period of transition. The primary mode of coexistence was dual-stack operation -- routers would be dual-stacked so that the network could carry both address families, and IPv6-capable hosts could be dual-stack to maintain access to IPv4-only partners. The goal was that the preponderance of hosts and routers in the Internet would be IPv6-capable long before IPv4 address space allocation was completed. At this time, it appears the exhaustion of IPv4 address space will occur before significant IPv6 adoption.
IPv4の設計により、IPv6がワイヤーに互換性があることが不可能になりましたが、設計者は、移行期間中にIPv4と共存することを意図しました。共存の主なモードはデュアルスタック操作でした。ルーターはデュアルスタックされ、ネットワークが両方のアドレスファミリを運ぶことができ、IPv6対応のホストはIPv4のみのパートナーへのアクセスを維持するためのデュアルスタックになります。目標は、インターネット内のホストとルーターの優位性がIPv6対応スペースの割り当てが完了するよりもずっと前にIPv6対応になることでした。この時点で、IPv4アドレススペースの疲労が大幅にIPv6採用前に発生するようです。
Curran's "A Transition Plan" [RFC5211] proposes a three-phase progression:
Curranの「移行計画」[RFC5211]は、3相の進行を提案しています。
Preparation Phase (current): characterized by pilot use of IPv6, primarily through transition mechanisms defined in [RFC4213], and planning activities.
準備段階（電流）：主に[RFC4213]で定義された遷移メカニズムと計画活動を通じて、IPv6のパイロット使用を特徴とします。
Transition Phase (2010 through 2011): characterized by general availability of IPv6 in provider networks, which should be native IPv6; organizations should provide IPv6 connectivity for their Internet-facing servers, but should still provide IPv4-based services via a separate service name.
遷移フェーズ（2010年から2011年まで）：プロバイダーネットワークでのIPv6の一般的な可用性を特徴とします。これはネイティブIPv6である必要があります。組織は、インターネット向けサーバーにIPv6接続を提供する必要がありますが、IPv4ベースのサービスを別のサービス名で提供する必要があります。
Post-Transition Phase (2012 and beyond): characterized by a preponderance of IPv6-based services and diminishing support for IPv4-based services.
移行後段階（2012年以降）：IPv6ベースのサービスの圧力とIPv4ベースのサービスのサポートの減少を特徴としています。
Various timelines have been discussed, but most will agree with the pattern of the above three transition phases, also known as an "S" curve transition pattern.
さまざまなタイムラインが議論されていますが、ほとんどは「S」曲線遷移パターンとしても知られる上記の3つの遷移フェーズのパターンに同意します。
In each of these phases, the coexistence problem and solution space have a different focus:
これらの各フェーズでは、共存の問題とソリューション空間には異なる焦点があります。
Preparation Phase: Coexistence tools are needed to facilitate early adopters by removing impediments to IPv6 deployment and to assure that nothing is lost by adopting IPv6 -- in particular, that the IPv6 adopter has unfettered access to the global IPv4 Internet regardless of whether they have a global IPv4 address (or any IPv4 address or stack at all). While it might appear reasonable for the cost and operational burden to be borne by the early adopter, the shared goal of promoting IPv6 adoption would argue against that model. Additionally, current IPv4 users should not be forced to retire or upgrade their equipment, and the burden remains on service providers to carry and route native IPv4. This is known as the early stage of the "S" curve.
準備フェーズ：IPv6の展開への障害を削除することにより早期採用者を促進し、特にIPv6採用者がグローバルIPv4インターネットへの自由なアクセスを持っていることを保証するためには、共存ツールが必要です。グローバルIPv4アドレス（または任意のIPv4アドレスまたはスタック）。コストと運用上の負担が早期の採用者によって負担されることは合理的に見えるかもしれませんが、IPv6の採用を促進するという共通の目標は、そのモデルに反対するでしょう。さらに、現在のIPv4ユーザーが機器を退職またはアップグレードすることを余儀なくされるべきではなく、ネイティブのIPv4を運ぶとルーティングするためにサービスプロバイダーに負担が残っています。これは、「S」曲線の初期段階として知られています。
Transition Phase: During the middle stage of the "S" curve, while IPv6 adoption can be expected to accelerate, there will still be a significant portion of the Internet operating IPv4-only or preferring IPv4. During this phase, the norm shifts from IPv4 to IPv6, and coexistence tools evolve to ensure interoperability between domains that may be restricted to IPv4 or IPv6.
遷移フェーズ：「S」曲線の中間段階では、IPv6の採用が加速することが予想されますが、IPv4のみを操作するインターネットの大部分がIPv4のみを操作します。このフェーズでは、NORMはIPv4からIPv6に移行し、共存ツールが進化してIPv4またはIPv6に制限される可能性のあるドメイン間の相互運用性を確保します。
Post-Transition Phase: This is the last stage of the "S" curve. In this phase, IPv6 is ubiquitous and the burden of maintaining interoperability shifts to those who choose to maintain IPv4-only systems. While these systems should be allowed to live out their economic life cycles, the IPv4-only legacy users at the edges should bear the cost of coexistence tools, and at some point service provider networks should not be expected to carry and route native IPv4 traffic.
移行後段階：これは「S」曲線の最後の段階です。このフェーズでは、IPv6は遍在しており、相互運用性を維持する負担は、IPv4のみのシステムを維持することを選択した人にシフトします。これらのシステムは経済的ライフサイクルを実現することを許可されている必要がありますが、エッジのIPv4のみのレガシーユーザーは共存ツールのコストを負担する必要があり、ある時点でサービスプロバイダーネットワークはネイティブのIPv4トラフィックを携帯してルーティングすることは期待されていません。
The choice between the terms "transition" versus "coexistence" has engendered long philosophical debate. "Transition" carries the sense that one is going somewhere, while "coexistence" seems more like one is sitting somewhere. Historically with the IETF, "transition" has been the term of choice [RFC4213] [RFC5211], and the tools for interoperability have been called "transition mechanisms". There is some perception or conventional wisdom that adoption of IPv6 is being impeded by the deficiency of tools to facilitate interoperability of nodes or networks that are constrained (in some way, fully or partially) from full operation in one of the address families. In addition, it is apparent that transition will involve a period of coexistence; the only real question is how long that will last.
「移行」と「共存」という用語の選択は、長い哲学的議論を生み出しました。「移行」とは、「共存」がどこかに座っているように見える一方、どこかに行くという感覚があります。歴史的にIETFでは、「遷移」が選択の用語であり[RFC4213] [RFC5211]、相互運用性のツールは「遷移メカニズム」と呼ばれています。IPv6の採用は、アドレスファミリのフル操作から（何らかの形で、または部分的に）制約されているノードまたはネットワークの相互運用性を促進するために、ツールの不足によって妨げられているという認識または従来の知恵があります。さらに、移行には共存の期間が含まれることが明らかです。唯一の本当の問題は、それがどれくらい続くかです。
Thus, coexistence is an integral part of the transition plan, not in conflict with it, but there will be a balancing act. It starts out being a way for early IPv6 adopters to easily exploit the bigger IPv4 Internet, and ends up being a way for late/never adopters to hang on with IPv4 (at their own expense, with minimal impact or visibility to the Internet). One way to look at solutions is that cost incentives (both monetary cost and the operational overhead for the end user) should encourage IPv6 and discourage IPv4. That way natural market forces will keep the transition moving -- especially as the legacy IPv4-only stuff ages out of use. The end goal should not be to eliminate IPv4 by fiat, but rather render it redundant through ubiquitous IPv6 deployment. IPv4 may never go away completely, but rational plans should move the costs of maintaining IPv4 to those who insist on using it after wide adoption of IPv6.
したがって、共存は移行計画の不可欠な部分であり、それと矛盾するものではありませんが、バランスの取れた行為があります。初期のIPv6アダプターがより大きなIPv4インターネットを簡単に活用する方法であり、最終的にはIPv4（インターネットへの影響や可視性が最小限で、独自の費用で、独自の費用で）を続ける方法になります。ソリューションを調べる1つの方法は、コストインセンティブ（金銭的コストとエンドユーザーの運用オーバーヘッドの両方）がIPv6を促進し、IPv4を阻止することです。そうすれば、自然市場の力は、特にLegacy IPv4のみのものが使用されていないため、移行を動かし続けます。最終目標は、FIATによってIPv4を排除することではなく、ユビキタスなIPv6展開を介して冗長化することです。IPv4は完全に消えることはないかもしれませんが、合理的な計画では、IPv4の幅広い採用後にIPv4を使用することを主張する人に維持するコストを移動する必要があります。
It is important to note that the choice of translation solution and the assumptions about the network where they are used impact the consequences. A translator for the general case has a number of issues that a translator for a more specific situation may not have at all.
翻訳ソリューションの選択と使用されるネットワークに関する仮定は、結果に影響を与えることに注意することが重要です。一般的なケースの翻訳者には、より具体的な状況の翻訳者がまったく持たないかもしれない多くの問題があります。
The intention of this document is to focus on translation solutions under all kinds of situations. All IPv4/IPv6 translation cases can be easily described in terms of "interoperation between a set of systems (applications) that only communicate using IPv4 and a set of systems that only communicate using IPv6", but the differences at a detailed level make them interesting.
このドキュメントの意図は、あらゆる種類の状況下で翻訳ソリューションに焦点を当てることです。すべてのIPv4/IPv6翻訳ケースは、「IPv4のみを使用して通信する一連のシステム（アプリケーション）とIPv6を使用して通信するシステムセット（アプリケーション）間の相互操作」の観点から簡単に説明できますが、詳細なレベルの違いにより興味深いものになります。。
Based on the transition plan described in Section 1.4, there are four types of IPv4/IPv6 translation cases:
セクション1.4で説明されている遷移計画に基づいて、IPv4/IPv6翻訳の4つのタイプがあります。
a. Interoperation between an IPv6 network and the IPv4 Internet
a. IPv6ネットワークとIPv4インターネットとの相互操作
b. Interoperation between an IPv4 network and the IPv6 Internet
b. IPv4ネットワークとIPv6インターネットとの相互操作
c. Interoperation between an IPv6 network and an IPv4 network
c. IPv6ネットワークとIPv4ネットワーク間の相互操作
d. Interoperation between the IPv6 Internet and the IPv4 Internet
d. IPv6インターネットとIPv4インターネットとの相互操作
Each one of the above can be divided into two scenarios, depending on whether the IPv6 side or the IPv4 side initiates communication, so there are a total of eight scenarios.
上記のそれぞれは、IPv6側が通信を開始するかどうかに応じて、2つのシナリオに分割できます。そのため、合計8つのシナリオがあります。
Scenario 1: an IPv6 network to the IPv4 Internet
シナリオ1：IPv4インターネットへのIPv6ネットワーク
Scenario 2: the IPv4 Internet to an IPv6 network
シナリオ2：IPv4インターネットからIPv6ネットワークへ
Scenario 3: the IPv6 Internet to an IPv4 network
シナリオ3：IPv6インターネットからIPv4ネットワークへ
Scenario 4: an IPv4 network to the IPv6 Internet
シナリオ4：IPv6インターネットへのIPv4ネットワーク
Scenario 5: an IPv6 network to an IPv4 network
シナリオ5：IPv4ネットワークへのIPv6ネットワーク
Scenario 6: an IPv4 network to an IPv6 network
シナリオ6：IPv6ネットワークへのIPv4ネットワーク
Scenario 7: the IPv6 Internet to the IPv4 Internet
シナリオ7：IPv4インターネットへのIPv6インターネット
Scenario 8: the IPv4 Internet to the IPv6 Internet
シナリオ8：IPv4インターネットへのIPv4インターネット
We will discuss each scenario in detail in the next section.
次のセクションで、各シナリオについて詳しく説明します。
Due to the lack of IPv4 addresses or due to other technical or economical constraints, the network is IPv6-only, but the hosts in the network require communicating with the global IPv4 Internet.
IPv4アドレスが不足しているため、または他の技術的または経済的な制約により、ネットワークはIPv6のみですが、ネットワークのホストはグローバルIPv4インターネットと通信する必要があります。
This is the typical scenario for what we sometimes call "green-field" deployments. One example is an enterprise network that wishes to operate only IPv6 for operational simplicity, but still wishes to reach the content in the IPv4 Internet. The green-field enterprise scenario is different from an ISP's network in the sense that there is only one place that the enterprise can easily modify: the border between its network and the IPv4 Internet. Obviously, the IPv4 Internet operates the way it already does. But, in addition, the hosts in the enterprise network are commercially available devices, personal computers with existing operating systems. This restriction drives us to a "one box" type of solution, where IPv6 can be translated into IPv4 to reach the public Internet.
これは、「グリーンフィールド」展開と呼ばれることの典型的なシナリオです。1つの例は、運用上のシンプルさのためにIPv6のみを操作することを希望するエンタープライズネットワークですが、それでもIPv4インターネットのコンテンツに到達したいと考えています。グリーンフィールドエンタープライズシナリオは、エンタープライズが簡単に変更できる場所が1つしかないという意味で、ISPのネットワークとは異なります。ネットワークとIPv4インターネットの境界です。明らかに、IPv4インターネットは既にそのように動作します。しかし、さらに、エンタープライズネットワークのホストは、既存のオペレーティングシステムを備えた市販のデバイス、パーソナルコンピューターです。この制限により、「1つのボックス」タイプのソリューションに駆り立てられ、IPv6をIPv4に翻訳してパブリックインターネットに到達できます。
Other cases that have been mentioned include wireless ISP networks and sensor networks. These bear a striking resemblance to this scenario as well, if one considers the ISP network to simply be a very special kind of enterprise network.
言及されている他のケースには、ワイヤレスISPネットワークとセンサーネットワークが含まれます。これらは、ISPネットワークが単に非常に特別な種類のエンタープライズネットワークであると考える場合、このシナリオにも驚くほど似ています。
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 1: Scenario 1
図1：シナリオ1
Both stateless and stateful solutions can support Scenario 1.
StatelessとStatefulの両方のソリューションは、シナリオ1をサポートできます。
When the enterprise networks or ISP networks adopt Scenario 1, the IPv6-only users will not only want to access servers on the IPv4 Internet but also will want to setup their own servers in the network that are accessible by the users on the IPv4 Internet, since the majority of the Internet users are still in the IPv4 Internet. Thus, with a translation solution for this scenario, the benefits would be clear. Not only could servers move directly to IPv6 without trudging through a difficult transition period, but they could do so without risk of losing connectivity with the IPv4-only Internet.
エンタープライズネットワークまたはISPネットワークがシナリオ1を採用する場合、IPv6のみのユーザーは、IPv4インターネット上のサーバーにアクセスするだけでなく、IPv4インターネット上のユーザーがアクセスできるネットワーク内の独自のサーバーをセットアップしたい場合もあります。インターネットユーザーの大部分はまだIPv4インターネットにいるためです。したがって、このシナリオの翻訳ソリューションを使用すると、利点は明確になります。サーバーは、困難な移行期間を駆け抜けることなくIPv6に直接移動できるだけでなく、IPv4のみのインターネットとの接続を失うリスクなしにそうすることができます。
--------
// \\ ----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \\ //
\\ // ----------
--------
====>
Figure 2: Scenario 2
図2：シナリオ2
In general, this scenario presents a hard case for translation. Stateful translation such as NAT-PT [RFC2766] can be used in this scenario, but it requires a tightly coupled DNS Application Level Gateway (ALG) in the translator, and this technique was deprecated by the IETF [RFC4966].
一般に、このシナリオは翻訳の難しいケースを示しています。このシナリオでは、NAT-PT [RFC2766]などの状態翻訳を使用できますが、翻訳者にはしっかりと結合したDNSアプリケーションレベルゲートウェイ（ALG）が必要であり、この手法はIETF [RFC4966]によって非推奨されました。
The stateless translation solution in Scenario 1 can also work in Scenario 2, since it can support IPv4-initiated communications with a subset of the IPv6 addresses (IPv4-translatable addresses) in an IPv6 network.
シナリオ1のステートレス翻訳ソリューションは、IPv6ネットワークのIPv6アドレス（IPv4翻訳可能アドレス）のサブセットとのIPv4によって開始された通信をサポートできるため、シナリオ2でも機能します。
There is a requirement for a legacy IPv4 network to provide services to IPv6 hosts.
Legacy IPv4ネットワークがIPv6ホストにサービスを提供する必要があります。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 3: Scenario 3
図3：シナリオ3
Stateless translation will not work for this scenario, because an IPv4 network needs to communicate with all of the IPv6 Internet, not just a small subset, and stateless can only support a subset of the IPv6 addresses. However, IPv6-initiated communication can be achieved through stateful translation. In this case, a Network Specific Prefix assigned to the translator will give the hosts unique IPv4-converted IPv6 addresses, no matter whether the legacy IPv4 network uses public IPv4 addresses or [RFC1918] addresses. Also there is no need to synthesize AAAA from A records, since static AAAA records can be put in the regular DNS to represent these IPv4-only hosts as discussed in Section 7.3 of [RFC6147].
IPv4ネットワークは、小さなサブセットだけでなく、IPv6アドレスのサブセットのみをサポートできるため、IPv4ネットワークがすべてのIPv6インターネットと通信する必要があるため、このシナリオではステートレス翻訳は機能しません。ただし、IPv6によって開始された通信は、ステートフル翻訳を通じて達成できます。この場合、翻訳者に割り当てられたネットワーク固有のプレフィックスは、Legacy IPv4ネットワークがパブリックIPv4アドレスまたは[RFC1918]アドレスを使用するかどうかに関係なく、ホストに一意のIPv4変換IPv6アドレスを提供します。また、[RFC6147]のセクション7.3で説明したように、これらのIPv4のみのホストを表すために静的AAAAレコードを通常のDNSに配置できるため、レコードからAAAAを合成する必要はありません。
Due to technical or economical constraints, the network is IPv4-only, and IPv4-only hosts (applications) may require communicating with the global IPv6 Internet.
技術的または経済的な制約により、ネットワークはIPv4のみであり、IPv4のみのホスト（アプリケーション）がグローバルIPv6インターネットとの通信が必要になる場合があります。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 | XLAT: IPv4/IPv6
| Network +----+ Internet | Translator
| |DNS | | DNS: DNS46
\ +----+ /
\\ // \ /
--------- \\ //
----------
=====>
Figure 4: Scenario 4
図4：シナリオ4
In general, this scenario presents a hard case for translation. Stateful translation such as NAT-PT [RFC2766] can be used in this scenario, but it requires a tightly coupled DNS ALG in the translator, and this technique was deprecated by the IETF [RFC4966].
一般に、このシナリオは翻訳の難しいケースを示しています。このシナリオでは、NAT-PT [RFC2766]などのステートフルな翻訳を使用できますが、翻訳者には緊密に結合されたDNSアルグが必要であり、この手法はIETF [RFC4966]によって非推奨されました。
From the transition phase discussion in Section 1.4, this scenario will probably only occur when we are well past the early stage of the "S" curve, and the IPv4/IPv6 transition has already moved to the right direction. Therefore, in-network translation is not considered viable for this scenario, and other techniques should be considered.
セクション1.4の遷移段階の議論から、このシナリオはおそらく「S」曲線の初期段階をはるかに超えている場合にのみ発生し、IPv4/IPv6遷移はすでに正しい方向に移動しています。したがって、ネットワーク内の翻訳はこのシナリオで実行可能であるとは見なされず、他の手法を考慮する必要があります。
In this scenario, both an IPv4 network and an IPv6 network are within the same organization.
このシナリオでは、IPv4ネットワークとIPv6ネットワークの両方が同じ組織内にあります。
The IPv4 addresses used are either public IPv4 addresses or [RFC1918] addresses. The IPv6 addresses used are either public IPv6 addresses or ULAs (Unique Local Addresses) [RFC4193].
使用されるIPv4アドレスは、パブリックIPv4アドレスまたは[RFC1918]アドレスのいずれかです。使用されるIPv6アドレスは、パブリックIPv6アドレスまたはULAS（一意のローカルアドレス）[RFC4193]です。
--------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 5: Scenario 5
図5：シナリオ5
The translation requirement from this scenario has no significant difference from Scenario 1, so both the stateful and stateless translation schemes discussed in Section 2.1 apply here.
このシナリオからの翻訳要件には、シナリオ1との大きな違いはありません。そのため、セクション2.1で説明したステートフルとステートレスの翻訳スキームの両方がここに適用されます。
This is another scenario when both an IPv4 network and an IPv6 network are within the same organization.
これは、IPv4ネットワークとIPv6ネットワークの両方が同じ組織内にある場合の別のシナリオです。
The IPv4 addresses used are either public IPv4 addresses or [RFC1918] addresses. The IPv6 addresses used are either public IPv6 addresses or ULAs (Unique Local Addresses) [RFC4193].
使用されるIPv4アドレスは、パブリックIPv4アドレスまたは[RFC1918]アドレスのいずれかです。使用されるIPv6アドレスは、パブリックIPv6アドレスまたはULAS（一意のローカルアドレス）[RFC4193]です。
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\\ // \\ //
-------- ---------
====>
Figure 6: Scenario 6
図6：シナリオ6
The translation requirement from this scenario has no significant difference from Scenario 2, so the translation scheme discussed in Section 2.2 applies here.
このシナリオからの翻訳要件には、シナリオ2との大きな違いはないため、セクション2.2で説明する翻訳スキームはここに適用されます。
This seems the ideal case for in-network translation technology, where any IPv6-only host or application on the global Internet can initiate communication with any IPv4-only host or application on the global Internet.
これは、グローバルインターネット上のIPv6のみのホストまたはアプリケーションがグローバルインターネット上のIPv4のみのホストまたはアプリケーションとの通信を開始できるネットワーク内翻訳テクノロジーにとって理想的なケースのようです。
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \ /
\\ // \\ //
-------- ---------
<====
Figure 7: Scenario 7
図7：シナリオ7
Due to the huge difference in size between the address spaces of the IPv4 Internet and the IPv6 Internet, there is no viable translation technique to handle unlimited IPv6 address translation.
IPv4インターネットとIPv6インターネットのアドレススペース間のサイズが大きく違いがあるため、無制限のIPv6アドレス変換を処理する実行可能な翻訳手法はありません。
If we ever run into this scenario, fortunately, the IPv4/IPv6 transition has already passed the early stage of the "S" curve. Therefore, there is no obvious business reason to demand a translation solution as the only transition strategy.
このシナリオに遭遇した場合、幸いなことに、IPv4/IPv6トランジションはすでに「S」曲線の初期段階を通過しています。したがって、翻訳ソリューションを唯一の移行戦略として要求する明らかなビジネス上の理由はありません。
This case is very similar to Scenario 7. The analysis and conclusions for Scenario 7 also apply for this scenario.
このケースは、シナリオ7と非常に似ています。シナリオ7の分析と結論もこのシナリオにも適用されます。
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \ /
\\ // \\ //
-------- ---------
====>
Figure 8: Scenario 8
図8：シナリオ8
Having laid out the preferred transition model and the options for implementing it (Section 1.1), defined terms (Section 1.2), considered the requirements (Section 1.3), considered the transition model (Section 1.4), and considered the kinds of scenarios the facility would support (Section 2), we now turn to a framework for IPv4/IPv6 translation. The framework contains the following components:
優先遷移モデルとそれを実装するためのオプション（セクション1.1）、定義された用語（セクション1.2）、要件（セクション1.3）を考慮し、遷移モデル（セクション1.4）を考慮し、施設のシナリオの種類を考慮したことをレイアウトした後、施設のシナリオの種類を考慮したサポート（セクション2）、IPv4/IPv6翻訳のフレームワークに目を向けます。フレームワークには、次のコンポーネントが含まれています。
o Address translation
o アドレス変換
o IP and ICMP translation
o IPおよびICMP翻訳
o Maintaining translation state
o 翻訳状態の維持
o DNS64 and DNS46
o DNS64およびDNS46
o ALGs for other application-layer protocols (e.g., FTP)
o 他のアプリケーション層プロトコルのアルグ（例：FTP）
When IPv6/IPv4 translation is performed, we should specify how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is used. This includes the choice of IPv6 prefix and the choice of method by which the remainder of the IPv6 address is derived from an IPv4 address [RFC6052]. The usages of the IPv6 addresses are shown in the following figures.
IPv6/IPv4の翻訳が実行される場合、アルゴリズムマッピングが使用される場合は、個々のIPv6アドレスが対応するIPv4アドレスにどのように変換されるかを指定する必要があります。これには、IPv6プレフィックスの選択と、IPv6アドレスの残りの部分がIPv4アドレス[RFC6052]から導出される方法の選択が含まれます。IPv6アドレスの使用法は、次の図に示されています。
------------
H4 - (IPv4 network) - IPv4 address corresponding to H6's IPv4-
(IPv4 ------------ translatable address
address) \
--------------
|Stateless XLAT|
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (IPv4-
----------- translatable address)
Figure 9: IPv6 Address Representation for Stateless Translation
図9：無国籍翻訳のIPv6アドレス表現
------------
H4 - (IPv4 network) - IPv4 address in the translator's IPv4 pool
(IPv4 ------------
address) \
--------------
|Stateful XLAT |
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (any IPv6 address)
-----------
Figure 10: IPv6 Address Representation for Stateful Translation
図10：ステートフル翻訳のIPv6アドレス表現
For both stateless and stateful translation, an algorithmic mapping table is used to translate IPv6 destination addresses (IPv4-converted addresses) to IPv4 destination addresses in the IPv6-to-IPv4 direction and translate IPv4 source addresses to IPv6 source addresses (IPv4-converted addresses) in the IPv4-to-IPv6 direction. Note that translating IPv6 source addresses to IPv4 source addresses in the IPv6-to-IPv4 direction and translating IPv4 destination addresses to IPv6 destination addresses in the IPv4-to-IPv6 direction will be different for stateless translation and stateful translation.
ステートレスとステートレスの両方の翻訳の両方で、アルゴリズムマッピングテーブルを使用して、IPv6-to-IPv4方向のIPv6宛先アドレス（IPv4コンバージドアドレス）をIPv4宛先アドレスに変換し、IPv4ソースアドレスをIPv6ソースアドレスに変換します（IPv4コンバージドアドレス（）IPv4-to-IPV6方向。IPv6ソースのアドレスをIPv6からIPV4への方向のIPv4ソースアドレスに翻訳し、IPv4対象アドレスをIPv4からIPV6への宛先アドレスに変換すると、ステートレス翻訳とステートフルな翻訳では異なります。
o For stateless translation, the same algorithmic mapping table is used to translate IPv6 source addresses (IPv4-translatable addresses) to IPv4 source addresses in the IPv6-to-IPv4 direction and translate IPv4 destination addresses to IPv6 destination addresses (IPv4-translatable addresses) in the IPv4-to-IPv6 direction. In this case, blocks of the service provider's IPv4 addresses are mapped into IPv6 and used by physical IPv6 nodes. The original IPv4 form of these blocks of the service provider's IPv4 addresses are used to represent the physical IPv6 nodes in IPv4. Note that stateless translation supports both IPv6 initiated as well as IPv4 initiated communications.
o ステートレス翻訳の場合、同じアルゴリズムマッピングテーブルを使用して、IPv6-to-IPv4方向のIPv6ソースアドレス（IPv4翻訳可能アドレス）をIPv4ソースアドレスに変換し、IPv4宛先アドレスをIPv6宛先アドレス（IPv4翻訳可能アドレス）に変換します（IPv4輸送可能なアドレス）IPv4-to-IPV6方向。この場合、サービスプロバイダーのIPv4アドレスのブロックはIPv6にマッピングされ、物理IPv6ノードによって使用されます。サービスプロバイダーのIPv4アドレスのこれらのブロックの元のIPv4形式は、IPv4の物理IPv6ノードを表すために使用されます。Stateless Translationは、IPv6が開始されたIPv4開始通信の両方をサポートしていることに注意してください。
o For stateful translation, the algorithmic mapping table is not used to translate source addresses in the IPv6-to-IPv4 direction and destination addresses in the IPv4-to-IPv6 direction. Instead, a state table is used to translate IPv6 source addresses to IPv4 source addresses in the IPv6-to-IPv4 direction and translate IPv4 destination addresses to IPv6 destination addresses in the IPv4- to-IPv6 direction. In this case, blocks of the service provider's IPv4 addresses are maintained in the translator as the IPv4 address pools and are dynamically bound to specific IPv6 addresses. The original IPv4 form of these blocks of the service provider's IPv4 addresses is used to represent the IPv6 address in IPv4. However, due to the dynamic binding, stateful translation in general only supports IPv6-initiated communication.
o ステートフルな翻訳の場合、アルゴリズムマッピングテーブルは、IPv6-to-IPV4の方向とIPv4-to-IPV6方向の宛先アドレスのソースアドレスを変換するために使用されません。代わりに、状態テーブルを使用して、IPv6-to-IPV4方向のIPv6ソースアドレスをIPv4ソースアドレスに変換し、IPv4-To-IPV6方向のIPv6宛先アドレスにIPv6宛先アドレスに変換します。この場合、サービスプロバイダーのIPv4アドレスのブロックは、IPv4アドレスプールとして翻訳者に維持され、特定のIPv6アドレスに動的に結合されます。サービスプロバイダーのIPv4アドレスのこれらのブロックの元のIPv4フォームは、IPv4のIPv6アドレスを表すために使用されます。ただし、動的な結合により、一般的なステートフルな翻訳はIPv6によって開始された通信のみをサポートしています。
The IPv4/IPv6 translator is based on the update to the Stateless IP/ ICMP Translation Algorithm (SIIT) described in [RFC2765]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers).
IPv4/ IPv6翻訳者は、[RFC2765]で説明されているStateless IP/ ICMP翻訳アルゴリズム（SIIT）の更新に基づいています。アルゴリズムは、IPv4とIPv6パケットヘッダー（ICMPヘッダーを含む）の間に変換されます。
The IP and ICMP translation document [RFC6145] discusses header translation for both stateless and stateful modes, but does not cover maintaining state in the stateful mode. In the stateless mode, translation is performed using a combination of information carried in the address and information configured in the translator. This permits both IPv4->IPv6 and IPv6->IPv4 session establishment. In the stateful mode, translation state is maintained between IPv4 address/ transport port tuples and IPv6 address/transport port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it.
IPおよびICMP翻訳ドキュメント[RFC6145]は、ステートレスモードとステートレスモードの両方のヘッダー翻訳について説明しますが、ステートフルモードでの維持状態をカバーしていません。ステートレスモードでは、翻訳が翻訳者で構成されたアドレスと情報の組み合わせを使用して実行されます。これにより、IPv4-> IPv6とIPv6-> IPv4セッションの確立の両方が許可されます。ステートフルモードでは、IPv4アドレス/トランスポートポートタプルとIPv6アドレス/トランスポートポートタプルの間で翻訳状態が維持され、IPv4システムを使用してIPv6システムがセッションを開くことができます。運用モードの選択は、ネットワークを展開するオペレーターによって行われ、それを使用したアプリケーションの動作に重要です。
For the stateful translator, besides IP and ICMP translation, special action must be taken to maintain the translation states. [RFC6146] describes a mechanism for maintaining state.
ステートフルな翻訳者の場合、IPおよびICMPの翻訳に加えて、翻訳状態を維持するために特別な行動をとる必要があります。[RFC6146]は、状態を維持するためのメカニズムを説明しています。
DNS64 [RFC6147] and possible future DNS46 documents describe the mechanisms by which a DNS translator is intended to operate. It is designed to operate on the basis of known address translation algorithms defined in [RFC6052].
DNS64 [RFC6147]および可能な将来のDNS46ドキュメントは、DNS翻訳者が動作することを目的としているメカニズムを説明しています。[RFC6052]で定義されている既知のアドレス変換アルゴリズムに基づいて動作するように設計されています。
There are at least two possible implementations of a DNS64 and DNS46:
DNS64とDNS46の実装が少なくとも2つあります。
Static records: One could literally populate DNS with corresponding A and AAAA records. This mechanism works for scenarios 2, 3, 5, and 6.
静的レコード：文字通り、対応するAおよびAAAAレコードを文字通りDNSに入力できます。このメカニズムは、シナリオ2、3、5、および6で機能します。
Dynamic Translation of static records: In more general operation, the preferred behavior is an A record to be (retrieved and) translated to a AAAA record by the DNS64 if and only if no reachable AAAA record exists, or for a AAAA record to be (retrieved and) translated to an A record by the DNS46 if and only if no reachable A record exists.
静的レコードの動的翻訳：より一般的な操作では、優先行動は、到達可能なAAAAレコードが存在しない場合、またはAAAAレコードが存在する場合にのみ、DNS64によってAAAAレコードに翻訳される（取得および）翻訳されるAレコードです。取得し、到達可能なレコードが存在しない場合にのみ、DNS46によって記録に翻訳されます。
In addition, some applications require special support. An example is FTP. FTP's active mode doesn't work well across NATs without extra support such as SOCKS [RFC1928] [RFC3089]. Across NATs, it generally uses passive mode. However, the designers of FTP wrote different and incompatible passive-mode implementations for IPv4 and IPv6 networks. Hence, either they need to fix FTP, or a translator must be written for the application. Other applications may be similarly broken.
さらに、一部のアプリケーションでは特別なサポートが必要です。例はFTPです。FTPのアクティブモードは、Socks [RFC1928] [RFC3089]などの追加のサポートがなければ、NATでうまく機能しません。NATを横切って、通常、パッシブモードを使用します。ただし、FTPの設計者は、IPv4およびIPv6ネットワークの異なるパッシブモード実装を書きました。したがって、FTPを修正する必要があるか、翻訳者をアプリケーション用に記述する必要があります。他のアプリケーションも同様に壊れている可能性があります。
As a general rule, a simple operational recommendation will work around many application issues: there should be a server in each domain, or an instance of the server should have an interface in each domain. For example, an SMTP MTA may be confused by finding an IPv6 address in its HELO when it is connected to using IPv4 (or vice versa), but would work perfectly well if it had an interface in both the IPv4 and IPv6 domains and was used as an application-layer bridge between them.
一般的なルールとして、単純な運用上の推奨事項は多くのアプリケーションの問題を回避します。各ドメインにサーバーがあるか、サーバーのインスタンスが各ドメインにインターフェイスを持つ必要があります。たとえば、SMTP MTAは、IPv4の使用に接続されている場合（またはその逆）、IPv6アドレスをHELOで見つけることで混乱する可能性がありますが、IPv4ドメインとIPv6ドメインの両方にインターフェイスがあり、使用された場合は完全にうまく機能します。それらの間のアプリケーション層橋として。
Currently, the proposed solutions for IPv6/IPv4 translation are classified into stateless translation and stateful translation.
現在、IPv6/IPv4翻訳の提案されたソリューションは、ステートレス翻訳とステートフルな翻訳に分類されています。
For stateless translation, the translation information is carried in the address itself plus configuration in the translators, permitting both IPv4->IPv6 and IPv6->IPv4 session initiation. Stateless translation supports end-to-end address transparency and has better scalability compared with stateful translation [RFC6145].
ステートレス翻訳の場合、翻訳情報はアドレス自体と翻訳者の構成に掲載され、IPv4-> IPv6とIPv6-> IPv4セッションの開始の両方が許可されます。ステートレス翻訳は、エンドツーエンドのアドレスの透明性をサポートし、ステートフルな翻訳と比較してスケーラビリティが向上しています[RFC6145]。
The stateless translation mechanisms typically put constraints on what IPv6 addresses can be assigned to IPv6 nodes that want to communicate with IPv4 destinations using an algorithmic mapping. For Scenario 1 ("an IPv6 network to the IPv4 Internet"), it is not a serious drawback, since the address assignment policy can be applied to satisfy this requirement for the IPv6 nodes that need to communicate with the IPv4 Internet. In addition, stateless translation supports Scenario 2 ("the IPv4 Internet to an IPv6 network"), which means that not only could servers move directly to IPv6 without trudging through a difficult transition period, but also they could do so without risk of losing connectivity with the IPv4- only Internet.
ステートレス翻訳メカニズムは通常、アルゴリズムマッピングを使用してIPv4宛先と通信したいIPv6ノードに割り当てることができるIPv6アドレスを割り当てることができるものに制約を掲載します。シナリオ1（「IPv4インターネットへのIPv6ネットワーク」）の場合、IPv4インターネットと通信する必要があるIPv6ノードのこの要件を満たすためにアドレス割り当てポリシーを適用できるため、深刻な欠点ではありません。さらに、Stateless Translationはシナリオ2（「IPv4インターネットからIPv6ネットワークへのインターネット」）をサポートしています。つまり、サーバーは困難な移行期間を駆け抜けることなくIPv6に直接移動できるだけでなく、接続性を失うリスクなしにそれを行うこともできます。IPv4-のみのインターネットで。
Stateless translation can be used for Scenarios 1, 2, 5, and 6, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv4 Internet to an IPv6 network", "an IPv6 network to an IPv4 network", and "an IPv4 network to an IPv6 network".
ステートレス翻訳は、シナリオ1、2、5、および6に使用できます。つまり、「IPv4インターネットへのIPv6ネットワーク」、「IPv4インターネットへのIPv6ネットワーク」、「IPv6ネットワークへのIPv4ネットワーク」、「IPv6ネットワークへのIPv4ネットワーク」。
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\ / \\ //
\\ // ----------
--------
<====>
Figure 11: Stateless Translation for Scenarios 1 and 2
図11：シナリオ1および2のステートレス翻訳
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\\ // \\ //
-------- ---------
<====>
Figure 12: Stateless Translation for Scenarios 5 and 6
図12：シナリオ5および6のステートレス翻訳
The implementation of the stateless translator needs to refer to [RFC6145] and [RFC6052].
ステートレス翻訳者の実装は、[RFC6145]および[RFC6052]を参照する必要があります。
For stateful translation, the translation state is maintained between IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv4 systems [RFC6145] [RFC6146].
ステートフルな翻訳のために、翻訳状態はIPv4アドレス/ポートペアとIPv6アドレス/ポートペアの間で維持され、IPv6システムがIPv4システム[RFC6145] [RFC6146]でセッションを開くことができます。
Stateful translation can be used for Scenarios 1, 3, and 5, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet to an IPv4 network", and "an IPv6 network to an IPv4 network".
ステートフルな翻訳は、シナリオ1、3、および5に使用できます。つまり、「IPv4インターネットへのIPv6ネットワーク」、「IPv6インターネットへのIPv4ネットワークへのインターネット」、および「IPv4ネットワークへのIPv6ネットワーク」をサポートします。
For Scenario 1, any IPv6 addresses in an IPv6 network can use stateful translation; however, it typically only supports initiation from the IPv6 side. In addition, it does not result in stable addresses of IPv6 nodes that can be used in DNS, which may cause problems for the protocols and applications that do not deal well with highly dynamic addresses.
シナリオ1の場合、IPv6ネットワーク内のIPv6アドレスは、ステートフルな翻訳を使用できます。ただし、通常、IPv6側からの開始のみをサポートします。さらに、DNSで使用できるIPv6ノードの安定したアドレスをもたらすことはありません。これにより、非常に動的なアドレスをうまく処理しないプロトコルとアプリケーションに問題を引き起こす可能性があります。
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 13: Stateful Translation for Scenario 1
図13：シナリオ1のステートフル翻訳1
Scenario 3 handles servers using IPv4 private addresses [RFC1918] and being reached from the IPv6 Internet. This includes cases of servers that for some reason cannot be upgraded to IPv6 and don't have public IPv4 addresses, and yet need to be reached by IPv6 nodes in the IPv6 Internet.
シナリオ3は、IPv4プライベートアドレス[RFC1918]を使用し、IPv6インターネットから到達しているサーバーを処理します。これには、何らかの理由でIPv6にアップグレードできず、パブリックIPv4アドレスがないが、IPv6インターネットのIPv6ノードで到達する必要があるサーバーのケースが含まれます。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 14: Stateful Translation for Scenario 3
図14：シナリオ3のステートフル翻訳
Similarly, stateful translation can also be used for Scenario 5.
同様に、ステートフルな翻訳はシナリオ5にも使用できます。
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 15: Stateful Translation for Scenario 5
図15：シナリオ5のステートフル翻訳5
The implementation of the stateful translator needs to refer to [RFC6145], [RFC6146], and [RFC6052].
ステートフル翻訳者の実装は、[RFC6145]、[RFC6146]、および[RFC6052]を参照する必要があります。
Based on the above analysis, the IPv4/IPv6 translation series consists of the following documents.
上記の分析に基づいて、IPv4/IPv6翻訳シリーズは次のドキュメントで構成されています。
o Framework for IPv4/IPv6 Translation (this document).
o IPv4/IPv6翻訳のフレームワーク（このドキュメント）。
o Address translation (the choice of IPv6 prefix and the choice of method by which the remainder of the IPv6 address is derived from an IPv4 address, part of the SIIT update) [RFC6052].
o アドレス変換（IPv6プレフィックスの選択と、IPv6アドレスの残りの部分がIPv4アドレスから派生した方法の選択、SIITアップデートの一部）[RFC6052]。
o IP and ICMP Translation (header translation and ICMP handling, part of the SIIT update) [RFC6145].
o IPおよびICMP翻訳（ヘッダー翻訳およびICMP処理、SIITアップデートの一部）[RFC6145]。
o Table maintenance (stateful translation including session database and mapping table handling) [RFC6146].
o テーブルメンテナンス（セッションデータベースとマッピングテーブル処理を含むステートフル翻訳）[RFC6146]。
o DNS64 (DNS64: A to AAAA mapping and DNSSEC discussion) [RFC6147].
o DNS64（DNS64：AからAAAAマッピングおよびDNSSECディスカッション）[RFC6147]。
o FTP ALG [FTP64].
o FTPアルグ[FTP64]。
o Others (DNS46, Multicast, etc.).
o その他（DNS46、マルチキャストなど）。
The relationship among these documents is shown in the following figure.
これらのドキュメント間の関係を次の図に示します。
-----------------------------------------
| Framework for IPv4/IPv6 Translation |
-----------------------------------------
|| ||
-------------------------------------------------------------------
| || stateless and stateful || |
| -------------------- --------------------- |
| |Address Translation | <======== | IP/ICMP Translation | |
| -------------------- --------------------- |
| /\ /\ |
| || ------------------||------------ |
| || | stateful \/ |
| ----------------- | --------------------- |
| | DNS64/DNS46 | | | Table Maintenance | |
| ----------------- | --------------------- |
-------------------------------------------------------------------
/\ /\
|| ||
----------------- --------------------
| FTP ALG | | Others |
----------------- --------------------
Figure 16: Document Layout
図16：ドキュメントレイアウト
In the document layout, the IP/ICMP Translation and DNS64/DNS46 normatively refer to Address Translation. The Table Maintenance and IP/ICMP Translation normatively refer to each other.
ドキュメントレイアウトでは、IP/ICMP翻訳とDNS64/DNS46は、アドレス変換を指すことです。テーブルメンテナンスとIP/ICMP翻訳は、互いに参照しています。
The FTP ALG and other documents normatively refer to the Address Format, IP/ICMP Translation, and Table Maintenance documents.
FTPアルグおよびその他のドキュメントは、通常、アドレス形式、IP/ICMP翻訳、およびテーブルメンテナンスドキュメントを指します。
Operationally, there are two ways that translation could be used -- as a permanent solution thereby making transition "the other guy's problem", and as a temporary solution for a new part of one's network while bringing up IPv6 services in the remaining parts of one's network. We obviously recommend the latter at the present stage. For the IPv4 parts of the network, [RFC4213]'s recommendation holds. Bring IPv6 up in those domains, move production to it, and then take down the now-unnecessary IPv4 service when economics warrant. This approach to transition entails the least risk.
運用上、翻訳を使用できる2つの方法があります - それによって「他の人の問題」を移行する永続的なソリューションとして、また自分のネットワークの新しい部分の一時的なソリューションとして、自分の残りの部分にIPv6サービスを持ち上げている間、通信網。現在の段階では、後者を明らかにお勧めします。ネットワークのIPv4部分の場合、[RFC4213]の推奨が保持されます。これらのドメインにIPv6を持ち上げ、生産を移動してから、経済学が必要な場合に不要なIPv4サービスを削除します。移行へのこのアプローチは、リスクが最も低くなります。
----------------------
////// \\\\\\
/// IPv4 or Dual Stack \\\
|| +----+ Routing +-----+ ||
| |IPv4| |IPv4+| |
| |Host| |IPv6 | |
|| +----+ |Host | ||
\\\ +-----+ ///
\\\\\----+----+-+-----+ +----+-/////
|XLAT|-|DNS64|-|FTP |
| |-|DNS46|-|ALG |
/////----+----+ +-----+ +----+-\\\\\
/// \\\
|| +-----+ +----+ ||
| |IPv4+| |IPv6| |
| |IPv6 | |Host| |
|| |Host | +----+ ||
\\\ +-----+ IPv6-only Routing ///
\\\\\\ //////
----------------------
Figure 17: Translation Operational Model
図17：翻訳運用モデル
Figure 17 shows that, during the coexistence phase, one expects a combination of hosts, applications, and networks. Hosts might include IPv6-only gaming devices and handsets, older computer operating systems that are IPv4-only, and modern mainline operating systems that support both. Applications might include ones that are IPv4-only and modern applications that support both IPv4 and IPv6. Networks might include dual-stack devices operating in single-stack networks (whether that stack is IPv4 or IPv6) and fully functional dual-stack networks.
図17は、共存段階で、ホスト、アプリケーション、およびネットワークの組み合わせを期待していることを示しています。ホストには、IPv6のみのゲームデバイスと携帯電話、IPv4のみの古いコンピューターオペレーティングシステム、両方をサポートする最新のメインラインオペレーティングシステムが含まれる場合があります。アプリケーションには、IPv4とIPv6の両方をサポートするIPv4のみのアプリケーションと最新のアプリケーションであるアプリケーションが含まれる場合があります。ネットワークには、シングルスタックネットワークで動作するデュアルスタックデバイス（そのスタックがIPv4またはIPv6であるかどうか）と完全に機能するデュアルスタックネットワークが含まれる場合があります。
The framework does not cover all possible scenarios, and it may be extended in the future to address them.
フレームワークは、可能なすべてのシナリオをカバーするものではなく、それらに対処するために将来拡張される可能性があります。
This document is the framework of IPv4/IPv6 translation. The security issues are addressed in individual IPv4/IPv6 translation documents, i.e., [RFC6052], [RFC6145], [RFC6146], [RFC6147], and [FTP64].
このドキュメントは、IPv4/IPv6翻訳のフレームワークです。セキュリティの問題は、個々のIPv4/IPv6翻訳ドキュメント、つまり[RFC6052]、[RFC6145]、[RFC6146]、[RFC6147]、および[FTP64]で対処されています。
This is under development by a large group of people. Those who have posted to the list during the discussion include Andrew Sullivan, Andrew Yourtchenko, Bo Zhou, Brian Carpenter, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Gang Chen, Hui Deng, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, and Remi Despres.
これは、大勢の人々によって開発中です。議論の中でリストに投稿した人には、アンドリュー・サリバン、アンドリュー・Yourtchenko、Bo Zhou、Brian Carpenter、Dan Wing、Dave Thaler、David Harrington、Ed Jankiewicz、Gang Chen、Hui Deng、Hui Deng、Hiroshi Miyata、Iljitch van Beijnum、John Schnizlein、マグナス・ウェスターランド、マルセロ・バグヌロ・ブラウン、マーガレット・ワッサーマン、マサヒート・エンド、フィル・ロバーツ、フィリップ・マシューズ、レミ・デニス・コールモント、レミ・デスプレス。
Ed Jankiewicz described the transition plan.
Ed Jankiewiczは移行計画について説明しました。
[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月。
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. 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. Beijnum、 "DNS64：DNS拡張IPv6クライアントからIPv4サーバーへのネットワークアドレス変換の拡張"、RFC 6147、2011年4月。
[6NET] 6NET Consortium, "6NET", <http://www.6net.org/>.
[6NET] 6NETコンソーシアム、「6NET」、<http://www.6net.org/>。
[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, March 2011.
[DS-Lite] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4 Exhotion後のデュアルスタックLite Broadband Deployments」、2011年3月、進行中の作業。
[FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
[FTP64] Beijnum、I。、「IPv6-to-IPV4翻訳用のFTPアルグ」、2011年3月の作業。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
[RFC1923] Halpern、J。およびS. Bradner、「歴史的地位のRIPV1アプリケーションステートメント」、RFC 1923、1996年3月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、 "Socks Protocolバージョン5"、RFC 1928、1996年3月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス変換 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089] Kitamura、H。、「ソックスベースのIPv6/IPv4ゲートウェイメカニズム」、RFC 3089、2001年4月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192] Baker、F.、Lear、E。、およびR. Droms、「フラグデーなしでIPv6ネットワークを変更するための手順」、RFC 4192、2005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966] AOUN、C。およびE. Davies、「ネットワークアドレス翻訳者を移動する理由 - プロトコル翻訳者（NAT -PT）は歴史的ステータスに」、RFC 4966、2007年7月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211] Curran、J。、「インターネット移行計画」、RFC 5211、2008年7月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムサンタバーバラ、カリフォルニア93117 USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China
Xing Li Cernet Center/Tsinghua University Room 225、メインビル、Tsinghua University Beijing、100084 China
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China
CONGXIAO BAO CERNET CENTER/Tsinghua University Room 225、メインビルディング、Tsinghua University Beijing、100084 China
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Kevin Yin Cisco Systems No. 2 Jianguomenwai Ave, Chaoyang District Beijing, 100022 China
Kevin Yin Cisco Systems No. 2 Jianguomenwai Ave、Chaoyang District Beijing、100022 China
Phone: +86-10-8515-5094
EMail: kyin@cisco.com