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
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変換するためのフレームワークについて説明します。プロトコル変換（NAT-PT）、RFC 4966によって非難し、IPv6ネットワークに移行しつつ幾分合理的に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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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へ移行しつつ幾分合理的にIPv4と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を使用して悪かったです。インターネットは、クラスレスドメイン間ルーティング（CIDR）に変換した時点でのRIPルーティングプロトコル[RFC1923]の非推奨と同様に、点は、実際に既知の問題が離れ技術から移動するためにネットワークオペレータを奨励することでした。
[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?
疑問が生じる：それが原因展開するために利用できる時間、または他の考慮に実行不可能であれば何？ネットワークとそのコンポーネントや顧客を移動するプロセスは、それが新しいサービスでグローバルIPv4アドレスを展開するために不経済になる点で重要な部分でのIPv6ターンアップを行うためには遅すぎる契約サイクルの開始された場合はどうすれば？どのようにしてネットワークをbalkanizingことなく、新たなサービスを展開し続けていますか？
This document describes translation as one of the tools networks might use to facilitate coexistence and ultimate transition.
この文書では、ネットワークが共存し、究極の移行を促進するために使用するかもしれないツールの一つとして翻訳を説明しています。
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:
トンネリングと翻訳：デュアルスタックの展開に加えて、1は、IPv4とIPv6の間のインターワーキングするために取ることができる二つの基本的なアプローチがあります。一つは、可能性 - と[6NET]で我々はなかった - 他の上で1つのプロトコルをトンネリングオーバーレイネットワークを構築します。様々な提案が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のみの展開を持っている特定のネットワーク。これは、企業の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のみの展開を持っている特定のネットワーク。これは、企業の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アドレスへの明示的なマッピング関係を持っています。ステートレスとステートフルの両方の翻訳者は、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の有効なエンド・システム・スタックを含む、アプリケーションは、直接的または間接的にそのIPv4スタックを使用して、プラスネットワークにおけるルーティング。これは、2つのアプリケーションインスタンスがIPv6 IPv4を使用して通信することができるが、ではないことを意味する - それらはIPv4ルーティングおよび潜在的には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はステートレス翻訳で使用するためのIPv6ノードに割り当てられるアドレス。彼らは、IPv4アドレスへの明示的なマッピング関係を持っています。ステートレストランスレータは、対応の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スタック、プラスネットワークにルーティングすることを使用してアプリケーション。これは、2つのアプリケーションインスタンスがIPv6を使用して通信することが可能であることを意味ではなく、IPv4が - それらが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アドレスとの間の動的な相関を意味します。ステートフルなアルゴリズムの、彼らは維持する状態の種類に応じて、少なくとも二つの主要なフレーバーがあります。
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パー、「『クライアント/サーバは、』 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アプリケーションがホストをピアリングに発信セッションを開始ならびにピアリングホストからの着信セッションを受け入れるように同じエンドポイントを使用するアプリケーションです。これらは、順番に二つのカテゴリーに大まかに分類できます。
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間のSMTP、ネットワークニュース、およびSIPが含まれます。任意の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.
ピアツーピアファイル交換アプリケーション：これらの例は、ライムワイヤー、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.
少なくとも2つのソフトウェアコンポーネント（同じまたは異なるシステムで実施することができるデータプレーントランスレータとDNSアプリケーション層ゲートウェイ）株および変換状態を調整しなければならない - NAT-PTは、既知の状態を有する設備の一例です。典型的なのIPv4 / IPv4のNATは、隠された状態でアルゴリズムを実装しています。変換テーブルとそれに関連する方法およびプロセスは、ステートフルなアルゴリズムに存在し、ステートレス1に存在しないので、明らかに、ステートレス翻訳は、ステートフルな翻訳よりも少ない計算オーバーヘッドを必要とし、少ないメモリ状態を維持します。
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のみのパートナーへのアクセスを維持するために、デュアルスタック可能性 - 共存の主なモードがデュアルスタック動作でした。目標は、インターネットでホストとルータの圧倒的多数は、IPv4アドレス空間の割り当てが完了したずっと前にIPv6対応になることでした。このとき、IPv4アドレス空間の枯渇が重要なのIPv6採用の前に発生します表示されます。
Curran's "A Transition Plan" [RFC5211] proposes a three-phase progression:
カランの「移行計画」[RFC5211]は、三相の進行を提案しています：
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.
遷移フェーズ（2011スルー2010）：プロバイダ・ネットワーク内の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採用に関係なく、彼らが持っているかどうかのグローバルなIPv4インターネットへの自由なアクセスを持っていることを、具体的には共存ツールは、IPv6展開に障害を除去することにより、早期導入を容易にし、何もIPv6を採用することにより、失われないことを保証するために必要とされていますグローバル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.
移行フェーズ：IPv6の採用が加速することが期待される一方で、「S」カーブの途中段階では、まだインターネットオペレーティングIPv4のみまたはIPv4を好むの重要な部分があるでしょう。このフェーズでは、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.
「共生」対用語「遷移」のどちらを選択するかは、長い哲学的な議論を生み出しています。 「遷移」「共生」は、より多くの1がどこかに座っているように思えるながら1は、どこかで起こっているという感覚を運びます。 IETFで歴史的に、「遷移は、」[RFC4213] [RFC5211]の選択の用語となっている、との相互運用性のためのツールは、「移行メカニズム」と呼ばれています。 IPv6の採用のは、アドレスファミリの1に（完全にまたは部分的に、何らかの方法で）フルオペレーションから拘束されているノードまたはネットワークの相互運用性を促進するためのツールの不足によって妨げられていることをいくつかの感覚や常識があります。また、遷移が共存期間を含むであろうことは明らかです。唯一の本当の問題は、それがいつまで続くです。
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でのハングアップしたように後半に採用決してための方法されて終わります。ソリューションを見るための一つの方法は、コストのインセンティブ（金銭的コストとエンドユーザーのための操作のオーバーヘッドの両方）がIPv6を奨励し、IPv4のを阻止すべきであるということです。そうすれば自然な市場の力は、トランジションを動かし続けるだろう - 特に使用のうち、従来のIPv4専用のスタッフの年齢として。最終目標は、フィアットことで、IPv4を排除するのではなく、ユビキタスのIPv6の展開を通じて、それは冗長なレンダリングするべきではありません。 IPv4が完全に消えることはありませんかもしれませんが、合理的な計画は、IPv6の広い採択後にそれを使う、という人には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側またはIPv4側が通信を開始するかどうかに応じて、2つのシナリオに分割することができるので、8つのシナリオの合計があります。
Scenario 1: an IPv6 network to the IPv4 Internet
シナリオ1：IPv6ネットワークのIPv4インターネットへ
Scenario 2: the IPv4 Internet to an IPv6 network
シナリオ2：IPv6ネットワークにIPv4インターネット
Scenario 3: the IPv6 Internet to an IPv4 network
シナリオ3：IPv4ネットワークへのIPv6インターネット
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：IPv6インターネットへの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.
これは、我々は時々、「グリーンフィールド」の展開と呼んでいるもののための典型的なシナリオです。一例としては、運用の簡素化のためにIPv6のみを操作することを希望する企業ネットワークであるが、それでもIPv4インターネットでのコンテンツに到達したいです。そのネットワークとIPv4インターネットとの間の境界：グリーンフィールドのエンタープライズ・シナリオは、企業が簡単に変更することができる唯一の場所があるという意味で、ISPのネットワークと異なっています。明らかに、IPv4インターネットがまだない方法を運営しています。しかし、加えて、企業ネットワーク内のホストは、市販の装置、既存のオペレーティングシステムとのパーソナルコンピュータで。この制限は、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のネットワークやセンサネットワークが含まれます。 1は、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.
ステートレスとステートフルの両方のソリューションは、シナリオ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.
それはIPv6ネットワークにおけるIPv6アドレス（IPv4に翻訳可能なアドレス）のサブセットとのIPv4が開始した通信をサポートすることができるので、シナリオ1におけるステートレス翻訳ソリューションはまた、シナリオ2で動作することができます。
There is a requirement for a legacy IPv4 network to provide services to IPv6 hosts.
IPv6ホストにサービスを提供するために、従来のIPv4ネットワークのための要件があります。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |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インターネットのすべてと通信する必要があるだけでなく、小さなサブセット、およびステートレスはIPv6アドレスだけのサブセットをサポートすることができますので、ステートレス翻訳は、このシナリオでは動作しません。ただし、IPv6が開始した通信は、ステートフル翻訳によって達成することができます。この場合、翻訳者に割り当てられたネットワーク固有の接頭辞は、ホストにレガシーIPv4ネットワークがパブリックIPv4アドレスまたは[RFC1918]のアドレスを使用するかどうかに関係なく、固有のIPv4変換IPv6アドレスを提供します。また、静的AAAAレコードは、[RFC6147]のセクション7.3で説明したように、これらのIPv4のみのホストを表すために、通常の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 ALGが必要であり、この技術は、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.
私たちは、「S」カーブの初期段階を過ぎてもされているとき、セクション1.4の移行段階の議論からは、このシナリオはおそらくのみ発生します、と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
IPおよびICMP翻訳O
o Maintaining translation state
変換状態を維持するO
o DNS64 and DNS46
OのDNS64とDNS46
o ALGs for other application-layer protocols (e.g., FTP)
他のアプリケーション層プロトコルのためのOのALG（例えば、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送信元アドレスにIPv4ソースアドレス（IPv4の変換アドレスのIPv6からIPv4方向にIPv4宛先アドレスへのIPv6宛先アドレス（IPv4の変換アドレス）を変換し、変換するために使用され）のIPv4からIPv6方向に移動します。 IPv6からIPv4方向にIPv4ソースアドレスとIPv6ソースアドレスを変換し、IPv4からIPv6方向にIPv6宛先アドレスにIPv4宛先アドレスを変換するステートレス翻訳およびステートフルな翻訳のために異なるであろうことに留意されたいです。
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宛先アドレスへのIPv4宛先アドレス（IPv4に並進アドレス）は、IPv6からIPv4方向にIPv4ソースアドレスとIPv6ソースアドレス（IPv4に翻訳可能なアドレス）を変換し、変換するために使用されIPv4からIPv6方向に移動します。この場合、サービスプロバイダのIPv4アドレスのブロックは、IPv6にマッピングされ、物理的なIPv6ノードによって使用されます。サービスプロバイダのIPv4アドレスのこれらのブロックのオリジナルのIPv4形式はIPv4の物理的なIPv6ノードを表すために使用されます。ステートレス翻訳がサポートしていることに注意してください両方の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、アルゴリズムマッピングテーブルはIPv4の対IPv6の方向でのIPv6からIPv4方向および宛先アドレスのソースアドレスを変換するために使用されていません。代わりに、状態テーブルは、IPv6からIPv4方向にIPv4ソースアドレスとIPv6ソースアドレスを変換し、IPv4-に、IPv6の方向にIPv6宛先アドレスにIPv4宛先アドレスを変換するために使用されます。この場合、サービスプロバイダの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トランスレータは、ステートレスIP / ICMP翻訳アルゴリズム[RFC2765]に記載の（SIIT）の更新に基づいています。このアルゴリズムは、（ICMPヘッダを含む）、IPv4およびIPv6パケットヘッダー間の変換します。
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の少なくとも二つの可能な実装があります。
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レコードに変換するためのレコードです（取り出され）到達可能なレコード番号が存在しない場合にのみ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の（またはその逆）を使用して接続されている場合、そのHELOにIPv6アドレスを見つけることによって混乱することができるが、それは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.
ステートレス変換メカニズムは、一般的にIPv6アドレスはアルゴリズムのマッピングを使用したIPv4の目的地と通信したいIPv6ノードに割り当てることができるものに制約を置きます。アドレス割り当てポリシーは、IPv4インターネットと通信する必要があるIPv6ノードのために、この要件を満たすために適用することができるので、シナリオ1（「IPv4インターネットへのIPv6ネットワーク」）のために、それは、重大な欠点ではありません。また、ステートレス翻訳は、シナリオ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".
「IPv4ネットワークへのIPv6ネットワーク」「IPv6ネットワークへのIPv4インターネット」ステートレス翻訳シナリオ1、2、5、6、すなわちのために使用することができ、それは「IPv4インターネットへのIPv6ネットワーク」をサポートし、、そして「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システム[RFC6145]、[RFC6146]とのセッションを開くために、IPv6システムを可能にする、IPv4のアドレス/ポートのペアとIPv6アドレス/ポートの対の間に維持されます。
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".
ステートフル翻訳は、「IPv4ネットワークにIPv6ネットワーク」「IPv6インターネットは、IPv4ネットワークに」、すなわち、それは「IPv4インターネットにIPv6ネットワーク」をサポートし、シナリオ1、3、及び5のために使用することができます。
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のためのステートフル翻訳
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のためのステートフル翻訳
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).
IPv4 / IPv6変換（本文書）のためのOフレームワーク。
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：AAAAマッピングとDNSSECの議論にA）[RFC6147]。
o FTP ALG [FTP64].
O FTP ALG [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 ALGおよびその他のドキュメントは、規範的にアドレスのフォーマット、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つの方法があり - 恒久的な解決策は、それによって「他の男の問題を」移行するように、そして自分のネットワークの新しい部分のための一時的な解決策としての1の残りの部分で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、ボー周、ブライアン・カーペンター、ダン・ウィング、デーブターラー、デヴィッド・ハリントン、エドJankiewicz、ギャング陳、ホイ鄧小、宮田宏、IljitschバンBeijnum、ジョンSchnizleinが含まれます、マグヌスウェスター、マルセロBagnuloブラウン、マーガレットワッサーマン、正人遠藤、フィル・ロバーツ、フィリップ・マシューズ、レミデニス・Courmont、およびレミ・デプレ。
Ed Jankiewicz described the transition plan.
エドJankiewiczは、移行計画を説明しました。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]バオ、C.、のHuitema、C.、Bagnulo、M.、Boucadair、M.、およびX.李、RFC 6052、2010年10月の "IPv6は、IPv4 / IPv6の翻訳者のアドレス指定"。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]のLi、X.、バオ、C.、およびF.ベイカー、 "IP / ICMP翻訳アルゴリズム"、RFC 6145、2011年4月。
[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.、マシューズ、P.、およびI. Beijnum、 "ステートフルNAT64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレスとプロトコル変換"、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.、サリバン、A.、マシューズ、P.、およびI. Beijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNSの拡張"、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]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "デュアルスタックLiteのブロードバンドの展開に続いてIPv4の枯渇"、進歩、2011年3月に作業。
[FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
[FTP64] Beijnum、I.、進歩、2011年3月に仕事の "IPv6からIPv4翻訳のためのFTP ALG"。
[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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
[RFC1923]ハルパーン、J.とS.ブラドナーの、 "歴史的な状態のための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]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、RFC 1928、1996年3月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmarkと、E.、 "ステートレス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]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089]北村、H.、 "SOCKSベースの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]ベイカー、F.、リア、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.ハーバーマン、 "ユニークローカル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.ギリガン、 "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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "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]アウン、C.およびE.デイヴィス、 "ネットワークアドレス変換に移動する理由 - 歴史的な状態にプロトコル変換（NAT-PT）" を、RFC 4966、2007年7月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211]カラン、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]テンプリン、F.、グリーソン、T.、およびD.ターラーは、 "イントラサイト自動トンネルは、プロトコル（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
電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China
興李CERNETセンター/清華大学ルーム225、本館、清華大学、北京、100084中国
Phone: +86 10-62785983 EMail: xing@cernet.edu.cn
電話：+86 10-62785983 Eメール：xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China
CongxiaoバオCERNETセンター/清華大学ルーム225、本館、清華大学、北京、100084中国
Phone: +86 10-62785983 EMail: congxiao@cernet.edu.cn
電話：+86 10-62785983 Eメール：congxiao@cernet.edu.cn
Kevin Yin Cisco Systems No. 2 Jianguomenwai Ave, Chaoyang District Beijing, 100022 China
ケビン・殷シスコシステムズ第2建国アベニュー、朝陽区、北京、100022中国
Phone: +86-10-8515-5094 EMail: kyin@cisco.com
電話：+ 86-10-8515-5094 Eメール：kyin@cisco.com