Internet Engineering Task Force (IETF) X. Li
Request for Comments: 6219 C. Bao
Category: Informational M. Chen
ISSN: 2070-1721 H. Zhang
J. Wu
CERNET Center/Tsinghua
University
May 2011
The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
中国教育研究ネットワーク（CERNET）のIPv4 / IPv6の共存と移行のためのIVI翻訳の設計と展開
Abstract
抽象
This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.
この文書では、IPv4 / IPv6の共存と移行のための中国教育研究ネットワーク（CERNET）のIVI翻訳設計と展開を提示します。
The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation.
IVIは、シナリオ「IPv6ネットワークにIPv4インターネット」「IPv4インターネットへのIPv6ネットワーク」との接頭辞特異的およびステートレスアドレスマッピングメカニズムです。 IVIの設計では、ISPのIPv4アドレスのサブセットは、ISPのIPv6アドレスに埋め込まれており、これらのIPv6アドレスを使用するホストは、したがって、直接グローバルIPv6インターネットと通信することができ、ステートレス翻訳を介してグローバルIPv4インターネットと通信することができます。通信は、IPv6を開始することができるいずれかまたはIPv4が開始しました。 IVIメカニズムは、エンドツーエンドのアドレス透明性と増分の展開をサポートしています。 IVIは、IPv4 / IPv6ステートレス翻訳上のIETF標準の文書のための基準としてCERNETに展開初期の設計です。
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/rfc6219.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6219で取得することができます。
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. Analysis of IPv4-IPv6 Translation Mechanisms ...............3
1.2. CERNET Translation Requirements ............................4
2. Terms and Abbreviations .........................................6
3. The IVI Translation Algorithm ...................................6
3.1. Address Format .............................................8
3.2. Routing and Forwarding .....................................9
3.3. Network-Layer Header Translation ..........................10
3.4. Transport-Layer Header Translation ........................11
3.5. Fragmentation and MTU Handling ............................11
3.6. ICMP Handling .............................................11
3.7. Application Layer Gateway .................................12
4. The IVI DNS Configuration ......................................12
4.1. DNS Configuration for the IVI6(i) Addresses ...............12
4.2. DNS Service for the IVIG6(i) Addresses ....................12
5. The Advanced IVI Translation Functions .........................12
5.1. IVI Multicast .............................................12
6. IVI Host Operation .............................................13
6.1. IVI Address Assignment ....................................13
6.2. IPv6 Source Address Selection .............................13
7. The IVI Implementation .........................................14
7.1. Linux Implementation ......................................14
7.2. Testing Environment .......................................14
8. Security Considerations ........................................14
9. Contributors ...................................................15
10. Acknowledgments ...............................................15
Appendix A. The IVI Translator Configuration Example ..............16
Appendix B. The traceroute Results ................................17
11. References ....................................................19
11.1. Normative References .....................................19
11.2. Informative References ...................................20
This document presents the CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. In Roman numerals, the "IV" stands for 4, and "VI" stands for 6, so "IVI" stands for the IPv4/IPv6 translation.
この文書では、IPv4 / IPv6の共存と移行のためのCERNET IVI翻訳設計と展開を提示します。ローマ数字では、「IV」は4の略で、「VIは」6の略で、その「IVIは、」IPv4の/ IPv6変換を表します。
The experiences with IPv6 deployment in the past 10 years indicate that the ability to communicate between IPv4 and IPv6 address families would be beneficial. However, the current transition methods do not fully support this requirement [RFC4213]. For example, dual-stack hosts can communicate with both the IPv4 and IPv6 hosts, but single-stack hosts can only communicate with hosts in the same address family. While the dual-stack approach continues to work in many cases even in the face of IPv4 address depletion [COUNT], there are situations where it would be desirable to communicate with a device in another address family. Tunneling-based architectures can link the IPv6 islands across IPv4 networks, but they cannot provide communication between the two different address families [RFC3056] [RFC5214] [RFC4380]. Translation can relay communications for hosts located in IPv4 and IPv6 networks, but the current implementation of this kind of architecture is not scalable, and it cannot maintain end-to-end address transparency [RFC2766] [RFC3142] [RFC4966] [RFC2775].
過去10年間でのIPv6の展開の経験では、IPv4およびIPv6アドレスファミリの間で通信する能力が有益であることを示しています。しかし、現在の遷移方法は、完全にこの要件[RFC4213]をサポートしていません。例えば、デュアルスタックホストがIPv4とIPv6の両方のホストと通信することができるが、シングルスタックホストは、同じアドレスファミリのホストと通信することができます。デュアルスタックアプローチも、IPv4アドレスの枯渇[COUNT]の面で多くの場合に動作し続けている間、別のアドレスファミリ内のデバイスと通信することが望ましい状況があります。トンネルベースのアーキテクチャは、IPv4ネットワークを介してIPv6の島をリンクすることができ、それらは二つの異なるアドレスファミリ[RFC3056]、[RFC5214]、[RFC4380]との間の通信を提供することができません。翻訳は、IPv4とIPv6ネットワークに位置するホストのための通信を中継することができるが、アーキテクチャのこの種の現在の実装は、スケーラブルではなく、それはエンド・ツー・エンドのアドレス透明[RFC2766]、[RFC3142]、[RFC4966]、[RFC2775]を維持することができません。
Since IPv4 and IPv6 are different protocols with different addressing structures, a translation mechanism is necessary for communication between endpoints using different address families. There are several ways to implement the translation. One is the Stateless IP/ ICMP Translation Algorithm (SIIT) [RFC2765], which provides a mechanism for translation between IPv4 and IPv6 packet headers (including ICMP headers) without requiring any per-connection state. However, SIIT does not specify the address assignment and routing scheme [RFC2766]. For example, SIIT uses IPv4-mapped IPv6 addresses [::ffff:ipv4-addr/96] and IPv4-compatible IPv6 addresses [::ipv4-address/96] for the address mapping, but these addresses violate the aggregation principle of IPv6 routing [RFC4291]. The other translation mechanism is Network Address Translation - Protocol Translation (NAT-PT), which has serious technical and operational difficulties; the IETF has reclassified it from Proposed Standard to Historic status [RFC4966].
IPv4とIPv6は異なるアドレッシング構造を有する異なるプロトコルであるので、翻訳機構が異なるアドレスファミリを使用して、エンドポイント間の通信のために必要です。翻訳を実装する方法はいくつかあります。一つは、任意の接続ごとの状態を必要とせずに（ICMPヘッダを含む）、IPv4およびIPv6パケットヘッダーの間で変換するための機構を提供するステートレスIP / ICMP翻訳アルゴリズム（SIIT）[RFC2765]です。しかし、SIITは、アドレス割り当ておよびルーティング方式[RFC2766]を指定していません。例えば、SIITは、IPv4マップIPv6アドレスを使用して[:: FFFF：のIPv4-ADDR / 96]とIPv4互換IPv6アドレス[::のIPv4アドレス/ 96]はアドレスマッピングのために、これらのアドレスは、IPv6の凝集原理に違反ルーティング[RFC4291]。他の翻訳メカニズムは、ネットワークアドレス変換である - 重大な技術的および運用の困難を持っているプロトコル変換（NAT-PT）、; IETFは、歴史的状況[RFC4966]へのProposed Standardからそれを再分類しました。
In order to solve the technical difficulties in NAT-PT, the issues and the possible workarounds are:
NAT-PTで技術的な問題を解決するために、問題と回避策は以下のとおりです。
1. NAT-PT disrupts all protocols that embed IP addresses (and/or ports) in packet payloads. There is little that can be done about this, other than using Application Layer Gateways (ALGs) or preferring protocols that transport DNS names instead of addresses.
1. NAT-PTはパケットのペイロードにIPアドレス（および/またはポート）を埋め込むすべてのプロトコルを破壊します。アプリケーションレイヤゲートウェイ（ALG）を使用して、またはトランスポートDNS名の代わりに、アドレスというプロトコルを好む以外に、これについて行うことができることはほとんどないです。
2. Loss of end-to-end address transparency may occur. End-to-end address transparency implies a global address space, the ability to pass packets unaltered throughout the network, and the ability to use source and destination addresses as unique labels [RFC2775]. A reversible, algorithmic mapping can restore some of this transparency. However, it is still not possible to ensure that all nodes in the existing Internet support such reversible mappings.
エンドツーエンドのアドレス透明の2損失が発生する可能性があります。エンドツーエンドのアドレス透明度は、グローバルアドレス空間、ネットワーク全体不変パケットを通過させる能力、および固有のラベル[RFC2775]として送信元および宛先アドレスを使用する能力を意味しています。可逆、アルゴリズムのマッピングは、この透明性の一部を復元することができます。しかし、そのような可逆マッピング既存のインターネットサポート内のすべてのノードことを保証することは可能ではありません。
3. The states maintained in the translator cause scalability, multihoming, and load-sharing problems. Hence, a stateless translation scheme is preferred.
翻訳原因スケーラビリティ、マルチホーミング、および負荷分散の問題で維持3.状態。したがって、ステートレス翻訳方式が好ましいです。
4. Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols may occur. A partial remedy to this is the proper attention to the details of the protocol translation, for example, the error-codes mapping between ICMP and ICMPv6. However, some semantic differences remain.
IPv4およびIPv6ヘッダのバージョンおよびプロトコルの間の互換性のない意味論への情報の4損失が発生する可能性があります。これに部分的な救済策は、例えば、プロトコル変換、ICMPおよびICMPv6の間のエラーコードのマッピングの詳細に適切な配慮です。しかし、いくつかの意味の違いが残っています。
5. The DNS is tightly coupled with the translator and lack of address mapping persistence discussed in Section 3.3 of [RFC4966]. Hence, the DNS should be decoupled from the translator.
5. DNSをしっかり翻訳と[RFC4966]のセクション3.3で説明したアドレスマッピング永続性の欠如と結合されています。したがって、DNSは、翻訳者からデカップリングする必要があります。
6. Support for referrals is difficult in NAT-PT, given that translated addresses may leak outside the network where these addresses have a meaning. Stateless translation, algorithmic address mappings, and the decoupling of DNS from the translation process can help the handling of referrals. Nevertheless, it is still possible that an address-based referral is passed to someone who cannot employ it. For instance, an IPv6-only node may pass a referral based on an IPv6 address to a node that only understands IPv4.
紹介6.サポートは、変換されたアドレスは、これらのアドレスが意味を持つネットワークの外に漏れることを考えると、NAT-PTに困難です。ステートレス翻訳、アルゴリズム・アドレスのマッピング、および翻訳プロセスからDNSのデカップリングは、紹介の取り扱いを助けることができます。それにも関わらず、アドレスベースの紹介がそれを採用することはできません誰かに渡されることは可能です。例えば、IPv6専用ノードは、IPv4のみを理解するノードにIPv6アドレスに基づいて、参照を渡すことができます。
The China Education and Research Network has two backbones using different address families. The CERNET is IPv4-only [CERNET] and CERNET2 is IPv6-only [CNGI-CERNET2], which fit in "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios in the IETF BEHAVE working group definition [BEHAVE]
中国教育研究ネットワークは、異なるアドレスファミリを使用して2つのバックボーンを持っています。 CERNETは[CERNET] IPv4のみであり、CERNET2はIETF BEHAVEワーキンググループシナリオ「IPv6ネットワークにIPv4インターネット」「IPv4インターネットへのIPv6ネットワーク」に収まるIPv6のみ[CNGI-CERNET2]、およびあります定義[BEHAVE]
[RFC6144]. In order to make CERNET2 communicate with the IPv4 Internet, we designed the IVI mechanism and installed IVI translators between the CERNET and CERNET2.
[RFC6144]。 CERNET2は、IPv4インターネットと通信させるために、我々は、IVIメカニズムを設計し、CERNETとCERNET2間のIVIトランスレータを設置しました。
The requirements of the IVI mechanism are:
IVI機構の要件は次のとおりです。
1. It should support both IPv6-initiated and IPv4-initiated communications for the IPv6 clients/servers in "an IPv6 network".
1.これは、「IPv6ネットワーク」でのIPv6クライアント/サーバー用の両方のIPv6-開始とIPv4-開始された通信をサポートする必要があります。
2. It should follow current IPv4 and IPv6 routing practice without increasing the global routing table size in both address families.
2.これは、両方のアドレスファミリでは、グローバルルーティングテーブルのサイズを大きくすることなく、現在のIPv4およびIPv6ルーティングの練習に従ってください。
4. It should be able to use IPv4 addresses effectively due to the IPv4 address depletion problem.
4. IPv4が原因のIPv4アドレス枯渇問題に効果的に対処し使用することができるはずです。
The specific IVI design presented in this document can satisfy the above requirements, with the following notes:
この文書の特定のIVIのデザインは、以下の点に注意して、上記の要件を満たすことができます。
1. It restricts the IPv6 hosts to use a subset of the addresses inside the ISP's IPv6 block. Therefore, IPv6 autoconfiguration cannot be used for these IPv6 hosts. Manual configuration or autoconfiguration via stateful DHCPv6 is required.
1.これは、IPv6がISPのIPv6アドレスブロック内のサブセットを使用するホスト制限します。そのため、IPv6自動設定では、これらのIPv6ホストのために使用することはできません。ステートフルDHCPv6のを経由して手動設定または自動設定が必要です。
2. It defines a one-to-one mapping between IPv4 addresses and IPv6 addresses; hence, the IPv4 addresses cannot be used efficiently. However, the IVI6 addresses can be used both for IPv6 clients and IPv6 servers. Due to this limitation, we suggest using IVI6 addresses for servers.
2.これは、IPv4アドレスとIPv6アドレスとの間の1対1のマッピングを定義します。したがって、IPv4アドレスを効率的に使用することができません。しかし、IVI6アドレスは、IPv6クライアントとIPv6サーバーの両方に使用することができます。この制限のため、我々はサーバー用IVI6アドレスを使用してお勧めします。
3. An ALG is still required for any applications that embed address(es) in the payload.
3.アンALGは依然としてペイロードにアドレスを埋め込む任意のアプリケーションのために必要とされます。
4. Some issues with end-to-end transparency, address referrals, and incompatible semantics between protocol versions still remain, as discussed above.
上述したように4プロトコルバージョンとの間のエンドツーエンドの透明度、アドレスの参照、および互換性のないセマンティクスを持ついくつかの問題が依然として残っています。
The IVI is an early design deployed in the CERNET for the stateless translation. The IETF standard IPv4-IPv6 stateless and stateful translation mechanisms are defined in [RFC6144], [RFC6052], [RFC6145], [RFC6146], and [RFC6147].
IVIは、ステートレスな翻訳にCERNETで展開初期の設計です。 IETF標準のIPv4-IPv6ステートレスとステートフル翻訳メカニズムは[RFC6144]、[RFC6052]、[RFC6145]、[RFC6146]及び[RFC6147]で定義されています。
The following terms and abbreviations are used in this document:
以下の用語および略語が本文書で使用されています。
ISP(i): A specific Internet service provider "i".
ISP（I）：特定のインターネットサービスプロバイダ "I"。
IVIG4: The global IPv4 address space.
IVIG4：グローバルIPv4アドレス空間。
IPS4(i): A subset of IVIG4 allocated to ISP(i).
IPS4（I）：ISP（I）に割り当てられIVIG4のサブセット。
IVI4(i): A subset of IPS4(i); the addresses in this set will be mapped to IPv6 via the IVI mapping mechanism and used by IPv6 hosts of ISP(i).
IVI4（I）：IPS4（I）のサブセット。このセットのアドレスは、IVIマッピング機構を介してIPv6へマッピングされ、ISPのIPv6ホスト（i）で使用されます。
IPG6: The global IPv6 address space.
IPG6：グローバルIPv6アドレス空間。
IPS6(i): A subset of IPG6 allocated to ISP(i).
IPS6（I）：ISP（I）に割り当てられIPG6のサブセット。
IVIG6(i): A subset of IPS6(i), and an image of IVIG4 in the IPv6 address family via the IVI mapping mechanism. It is defined as the IPv4-converted address in [RFC6144].
IVIG6（I）：IPS6（I）のサブセット、およびIVIマッピング機構を介してIPv6アドレスファミリにおけるIVIG4の画像。これは[RFC6144]でのIPv4アドレス変換として定義されます。
IVI6(i): A subset of IVIG6(i) and an image of IVI4(i) in the IPv6 address family via the IVI mapping mechanism. It is defined as the IPv4-translatable address in [RFC6144].
IVI6（I）：IVIマッピング機構を介してIPv6アドレスファミリにおけるIVIG6（i）およびIVI4（I）の画像のサブセット。これは[RFC6144]でのIPv4翻訳可能アドレスとして定義されます。
IVI translator: The mapping and translation gateway between IPv4 and IPv6 based on the IVI mechanism.
IVIトランスレータ：IVIメカニズムに基づいて、IPv4とIPv6との間のマッピングおよび変換ゲートウェイ。
IVI DNS: Providing the IVI Domain Name System (DNS).
IVI DNS：IVIドメインネームシステム（DNS）を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this document, are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、彼らが表示されたときに、 "NOT SHALL" "ものとし"、、、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、および "OPTIONAL"この文書では、[RFC2119]に記載されているように解釈されるべきです。
The IVI is a prefix-specific and stateless address mapping scheme that can be carried out by individual ISPs. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated.
IVIは、個々のISPによって行うことができるプレフィックス固有およびステートレスアドレスマッピング方式です。 IVIの設計では、ISPのIPv4アドレスのサブセットは、ISPのIPv6アドレスに埋め込まれており、これらのIPv6アドレスを使用するホストは、したがって、直接グローバルIPv6インターネットと通信することができ、ステートレス翻訳を介してグローバルIPv4インターネットと通信することができます。通信は、IPv6を開始することができるいずれかまたはIPv4が開始しました。
The IVI mapping and translation mechanism is implemented in an IVI translator that connects between "an IPv6 network" and the IPv4 Internet via the ISP's IPv4 network, as shown in the following figure.
次の図に示すようにIVIマッピング及び翻訳機構は、ISPのIPv4ネットワークを介して、「IPv6ネットワーク」とIPv4インターネットとの間を接続するIVIトランスレータに実装されます。
------ ----- ------
/ The \ ----- / An \ / The \
| IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 |
\Internet/ ----- \Network/ \Internet/
------ ----- ------
<===>
Figure 1: The Scenarios: "An IPv6 Network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 Network"
図1：シナリオ：「IPv6ネットワークにIPv4インターネット」「IPv4インターネットとIPv6ネットワーク」と
In order to perform the translation function between IPv4 and IPv6 addresses, the translator needs to represent the IPv4 addresses in IPv6 and the IPv6 addresses in IPv4.
IPv4アドレスとIPv6アドレス間の変換機能を実行するために、翻訳者は、IPv6でのIPv4アドレスを表現するために必要とIPv6は、IPv4のアドレス。
To represent the IPv4 addresses in IPv6, a unique, prefix-specific, and stateless mapping scheme is defined between IPv4 addresses and subsets of IPv6 addresses, so each provider-independent IPv6 address block (usually a /32) will have a small portion of IPv6 addresses (for example, /40 defined by PREFIX), which is the image of the totality of the global IPv4 addresses, as shown in the following figure. The SUFFIX is all zeros.
IPv6の内のIPv4アドレスを表すためにユニークな、接頭固有、およびステートレスなマッピングスキームは、IPv4アドレスとIPv6アドレスのサブセットなので、各プロバイダに依存しないIPv6アドレスブロック（通常/ 32）の小さな部分を有するであろうとの間に画定されます次の図に示すように、グローバルIPv4アドレスの全体の画像であるIPv6アドレス（PREFIXによって定義され、例えば、/ 40）。接尾辞はすべてゼロです。
+-+-+-+-+-+-+
| IVIG4 |
+-+-+-+-+-+-+
||
\ /
\/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX | IPv4 addr | SUFFIX |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: Representing the IPv4 Addresses in IPv6
図2：IPv6の内のIPv4アドレスを表します
To represent the IPv6 addresses in IPv4, each provider can borrow a portion of its IPv4 addresses and map them into IPv6 based on the above mapping rule. These special IPv6 addresses will be physically used by IPv6 hosts. The original IPv4 form of the borrowed addresses is the image of these special IPv6 addresses, and it can be accessed by the IPv4 Internet, as shown in the following figure. The SUFFIX can either be all zeros, or some other value for future extensions.
IPv4のIPv6アドレスを表すために、各プロバイダは、そのIPv4アドレスの一部を借りて上記マッピング規則に基づいたIPv6にそれらをマッピングすることができます。これらの特別なIPv6アドレスは、物理的にIPv6ホストによって使用されます。借用アドレスのオリジナルのIPv4形態では、これらの特別なIPv6アドレスの画像であり、次の図に示すように、それは、IPv4インターネットによってアクセスすることができます。サフィックスは、どちらかのすべてゼロ、または将来の拡張のためのいくつかの他の値にすることができます。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX | |IVI4| | SUFFIX |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
\ /
\/
-+-+-+
|IVI4|
-+-+-+
Figure 3: Representing the IPv6 Addresses in IPv4
図3：IPv4のIPv6アドレスを表現
The IVI address format is defined based on an individual ISP's IPv6 prefix, as shown in the following figure
次の図に示すように、IVIアドレスフォーマットは、個々のISPのIPv6プレフィックスに基づいて定義されます
| 0 |32 |40 |72 127|
------------------------------------------------------------------
| |ff | | |
------------------------------------------------------------------
|<- PREFIX ->|<- IPv4 address ->| <- SUFFIX -> |
Figure 4: IVI Address Mapping
図4：IVIアドレスのマッピング
where bit 0 to bit 31 are the prefix of ISP(i)'s /32 (e.g., using document IPv6 address IPS6=2001:db8::/32) in the CERNET implementation, bit 32 to bit 39 are all ones as the identifier of the IVI addresses, and bit 40 to bit 71 are embedded global IPv4 space (IVIG4), presented in hexadecimal format (e.g., 2001:db8:ff00::/40). Note that based on the IVI mapping mechanism, an IPv4 /24 is mapped to an IPv6 /64, and an IPv4 /32 is mapped to an IPv6 /72.
ビット31のビット0は、ISP（I）の/ 32（例えば、使用して文書IPv6アドレスIPS6 = 2001：DB8 :: / 32）の接頭辞である場合CERNETの実装において、ビット39から32は、などのすべてのものであるビットIVIアドレスの識別子、および、ビット71から40は、16進形式で提示され、グローバルIPv4スペース（IVIG4）が埋め込まれているビット（例えば、2001：DB8：FF00 :: / 40）。 IVIマッピングメカニズムに基づいなお、IPv4の/ 24は、IPv6 / 64にマッピングされ、とIPv4 / 32は、IPv6 / 72にマッピングされます。
The IETF standard for the address format is defined in [RFC6052].
アドレス形式のためのIETF標準は、[RFC6052]で定義されています。
Based on the IVI address mapping rule, routing is straightforward, as shown in the following figure
次の図に示すようにIVIアドレスマッピングルールに基づいて、ルーティングは、簡単です
/-----\ /-----\
( ISP's ) -- 192.0.2.2 ----------- 2001:db8::2 -- ( ISP's )
( IPv4 )--|R1|-------------| IVI Xlate |------------|R2|---( IPv6 )
(network) -- 192.0.2.1 ----------- 2001:db8::1 -- (network)
\-----/ \-----/
| |
| |
The IPv4 Internet The IPv6 Internet
Figure 5: IVI Routing
図5：IVIルーティング
where
どこ
1. IVI Xlate is a special dual-stack router, with two interfaces, one to the IPv4 network and the other to the IPv6 network (it is also possible to have a single interface configured with both IPv4 and IPv6 addresses). IVI Xlate can support dynamic routing protocols in IPv4 and IPv6 address families. In the above configuration, the static routing configuration can be used.
1. IVI XLATE 2つのインターフェイス、IPv6ネットワークにIPv4ネットワークへの1つ及び他の（IPv4およびIPv6アドレスの両方で構成された単一のインターフェースを有することも可能である）と、特別なデュアルスタックルータです。 IVI XLATEは、IPv4およびIPv6アドレスファミリでダイナミックルーティングプロトコルをサポートすることができます。上記構成では、静的ルーティング構成を使用することができます。
2. Router R1 has an IPv4 route for IVI4(i)/k (k is the prefix length of IVI4(i)) with the next hop equal to 192.0.2.1, and this route is distributed to the Internet with proper aggregation.
2.ルータR1は192.0.2.1に等しい次のホップとIVI4（I）/ K（KはIVI4（I）のプレフィックス長である）のIPv4経路を有しており、この経路は、適切な凝集にインターネットに分配されます。
3. Router R2 has an IPv6 route for IVIG6(i)/40 with the next hop equal to 2001:db8::1, and this route is distributed to the IPv6 Internet with proper aggregation.
3.ルータR2は、2001年に等しい次のホップとIVIG6（I）/ 40のIPv6ルート有する：DB8 :: 1を、この経路は、適切な凝集とIPv6インターネットに分配されます。
4. The IVI translator has an IPv6 route for IVI6(i)/(40+k) with the next hop equal to 2001:db8::2. The IVI translator also has an IPv4 default route 0.0.0.0/0 with the next hop equal to 192.0.2.2.
DB8 :: 2：4 IVIトランスレータ2001に等しい次のホップとIVI6（I）/（40 + K）のIPv6ルートを有しています。 IVIトランスレータはまた、192.0.2.2に等しい次のホップとのIPv4デフォルトルート0.0.0.0/0を有しています。
Note that the routes described above can be learned/inserted by dynamic routing protocols (IGP or BGP) in the IVI translator peering with R1 and R2.
上記ルートはR1とR2とのピアリングIVIトランスレータに動的ルーティングプロトコル（IGPまたはBGP）によって挿入/学習することができることに留意されたいです。
Since both IVI4(i) and IVI6(i) are aggregated to IPS4(i) and IPS6(i) in ISP(i)'s border routers, respectively, they will not affect the global IPv4 and IPv6 routing tables [RFC4632].
IVI4（i）およびIVI6（I）の両方が、ISP（I）の境界ルータにIPS4（i）およびIPS6（I）に集約されているので、それぞれ、それらはグローバルIPv4およびIPv6ルーティングテーブル[RFC4632]を影響しないであろう。
Since the IVI translation is stateless, it can support multihoming when the same prefix is used for multiple translators.
IVI翻訳はステートレスであるので、同じプレフィックスを複数の翻訳者に使用されている場合、それはマルチホーミングをサポートすることができます。
Since the IVI translation can be implemented independently in each ISP's network, it can be incrementally deployed in the global Internet.
IVIの翻訳は、各ISPのネットワーク内に独立して実装することができますので、それは漸増グローバルインターネットで展開することができます。
IPv4 [RFC0791] and IPv6 [RFC2460] are different protocols with different network-layer header formats; the translation of the IPv4 and IPv6 headers MUST be performed according to SIIT [RFC2765], except for the source and destination addresses in the header, as shown in the following figures.
IPv4の[RFC0791]とIPv6 [RFC2460]は、異なるネットワーク層ヘッダフォーマットと異なるプロトコルです。以下の図に示すように、IPv4とIPv6ヘッダの変換は、ヘッダ内の送信元アドレスと宛先アドレスを除いて、SIIT [RFC2765]に従って実施しなければなりません。
-------------------------------------------------------------
IPv4 Field Translated to IPv6
-------------------------------------------------------------
Version (0x4) Version (0x6)
IHL discarded
Type of Service Traffic Class
Total Length Payload Length = Total Length - 20
Identification discarded
Flags discarded
Offset discarded
TTL Hop Limit
Protocol Next Header
Header Checksum discarded
Source Address IVI address mapping
Destination Address IVI address mapping
Options discarded
-------------------------------------------------------------
Figure 6: IPv4-to-IPv6 Header Translation
図6：のIPv4からIPv6ヘッダ変換
-------------------------------------------------------------
IPv6 Field Translated to IPv4 Header
-------------------------------------------------------------
Version (0x6) Version (0x4)
Traffic Class Type of Service
Flow Label discarded
Payload Length Total Length = Payload Length + 20
Next Header Protocol
Hop Limit TTL
Source Address IVI address mapping
Destination Address IVI address mapping
- IHL = 5
- Header Checksum recalculated
-------------------------------------------------------------
Figure 7: IPv6-to-IPv4 Header Translation
図7のIPv6からIPv4ヘッダ変換
The IETF standard for IP/ICMP translation is defined in [RFC6145], which contains updated technical specifications.
IP / ICMPの翻訳のためのIETF標準を更新技術仕様が含まれて、[RFC6145]で定義されています。
Since the TCP and UDP headers [RFC0793] [RFC0768] consist of checksums that include the IP header, the recalculation and updating of the transport-layer headers MUST be performed. Note that SIIT does not recalculate the transport-layer checksum, since checksum-neutral IPv6 addresses are used in SIIT [RFC2765].
TCPおよびUDPヘッダー[RFC0793]、[RFC0768] IPヘッダを含むチェックサムで構成されているので、トランスポート層ヘッダの再計算及び更新が行われなければなりません。チェックサム中立IPv6アドレスをSIIT [RFC2765]で使用されているのでSIITは、トランスポート層チェックサムを再計算しないことに注意してください。
The IETF standard for transport-layer header translation is defined in [RFC6145], which contains updated technical specifications.
トランスポート層ヘッダ変換のためのIETF標準を更新技術仕様を含む、[RFC6145]で定義されています。
When the packet is translated by the IVI translator, due to the different sizes of the IPv4 and IPv6 headers, the IVI6 packets will be at least 20 bytes larger than the IVI4 packets, which may exceed the MTU of the next link in the IPv6 network. Therefore, the MTU handling and translation between IPv6 fragmentation headers and the fragmentation field in the IPv4 headers are necessary; this is performed in the IVI translator according to SIIT [RFC2765].
パケットによるIPv4およびIPv6ヘッダの異なるサイズに、IVI変換によって変換されたときに、IVI6パケットは、IPv6ネットワーク内の次のリンクのMTUを超える可能性がある、IVI4パケットより少なくとも20バイト大きくなり。したがって、IPv4のヘッダ内のIPv6フラグメンテーションヘッダーと断片化フィールドとの間のMTU処理および翻訳が必要です。これは、SIIT [RFC2765]に記載IVIトランスレータで実行されます。
The IETF standard for fragmentation and MTU handling is defined in [RFC6145], which contains updated technical specifications.
フラグメンテーションとMTU処理のためのIETF標準を更新技術仕様が含まれて、[RFC6145]で定義されています。
For ICMP message translation between IPv4 and IPv6, IVI follows the ICMP/ICMPv6 message correspondence as defined in SIIT [RFC2765]. Note that the ICMP message may be generated by an intermediate router whose IPv6 address does not belong to IVIG6(i). Since ICMP translation is important to the path MTU discovery and troubleshooting, the IPv4 representation of the non-IVIG6 addresses in the ICMP packets is required. In the current IVI prototype, a small IPv4 address block is used to identify the non-IVIG6 addresses. This prevents translated ICMP messages from being discarded due to unknown or private IP sources.
SIIT [RFC2765]で定義されるように、IPv4とIPv6との間のICMPメッセージ翻訳のために、IVIは、ICMP / ICMPv6メッセージの対応を以下。 ICMPメッセージは、そのIPv6のアドレスIVIG6（I）に属していない中間ルータによって生成されてもよいことに留意されたいです。 ICMPの翻訳はパスMTUディスカバリおよびトラブルシューティングに重要であるので、ICMPパケット内の非IVIG6アドレスのIPv4の表現が必要です。現在IVIプロトタイプでは、小さなIPv4アドレスブロックが非IVIG6アドレスを識別するために使用されます。これは、不明またはプライベートIPソースに捨てられるから翻訳されたICMPメッセージを防ぎます。
The IETF standard for IP/ICMP translation is defined in [RFC6145], which contains updated technical specifications.
IP / ICMPの翻訳のためのIETF標準を更新技術仕様が含まれて、[RFC6145]で定義されています。
Due to the features of 1-to-1 address mapping and stateless operation, IVI can support most of the existing applications, such as HTTP, Secure SHell (SSH), and Telnet. However, some applications are designed such that IP addresses are used to identify application-layer entities (e.g., FTP). In these cases, an Application Layer Gateway (ALG) is unavoidable, and it can be integrated into the IVI translator.
1対1のアドレスマッピングとステートレス操作の特徴に、IVIは、HTTP、セキュアシェル（SSH）、およびTelnetなどの既存のアプリケーションのほとんどをサポートすることができます。しかし、一部のアプリケーションは、IPアドレスをアプリケーション層エンティティ（例えば、FTP）を同定するために使用されるように設計されます。これらのケースでは、アプリケーションレイヤゲートウェイ（ALG）は避けられない、そしてそれはIVIトランスレータに統合することができます。
The discussion of the use of ALGs is in [RFC6144].
ALGの使用の議論は[RFC6144]です。
The DNS [RFC1035] service is important for the IVI mechanism.
DNS [RFC1035]サービスは、IVIのメカニズムのために重要です。
For providing authoritative DNS service for IVI4(i) and IVI6(i), each host name will have both an A record and a AAAA record pointing to IVI4(i) and IVI6(i), respectively. Note that the same name always points to a unique host, which is an IVI6(i) host, and it has IVI4(i) representation via the IVI translator.
IVI4（i）およびIVI6（I）に対する権限DNSサービスを提供するために、各ホスト名はそれぞれIVI4（i）およびIVI6（I）のレコードとAAAAレコードポインティング両方を有することになります。同じ名前が常にIVI6（I）のホストであり、それは、IVIトランスレータを経由してIVI4（I）の表現を持っている固有のホスト、を指していることに注意してください。
For resolving the IPv6 form of the global IPv4 space (IVIG6(i)), each ISP must provide customized IVI DNS service for the IVI6(i) hosts. The IVI DNS server MUST be deployed in a dual-stack environment. When the IVI6(i) host queries a AAAA record for an IPv4-only domain name, the IVI DNS will query the AAAA record first. If the AAAA record does not exist, the IVI DNS will query the A record and map it to IVIG6(i), and return a AAAA record to the IVI6(i) host. The technical specifications for this process are defined in [RFC6147].
グローバルIPv4スペース（IVIG6（I））のIPv6の形を解決するために、各ISPはIVI6（I）ホスト用にカスタマイズIVIのDNSサービスを提供しなければなりません。 IVIのDNSサーバは、デュアルスタック環境に展開する必要があります。 IVI6（ⅰ）ホストはIPv4のみのドメイン名のAAAAレコードを照会すると、IVI DNSは、最初のAAAAレコードを照会します。 AAAAレコードが存在しない場合は、IVI DNSがAレコードを照会し、IVIG6（I）にマッピングし、IVI6（I）ホストにAAAAレコードを返します。このプロセスのための技術仕様は、[RFC6147]で定義されています。
The IVI mechanism can support IPv4/IPv6 communication of Protocol Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC5771] [RFC3569] [RFC4607].
ソース固有マルチキャスト（PIM-SSM）[RFC5771]、[RFC3569]、[RFC4607] - IVI機構はプロトコル独立マルチキャストのIPv4 / IPv6通信をサポートすることができます。
There will be 2^24 group addresses for IPv4 SSM. The corresponding IPv6 SSM group addresses can be defined as shown in the following figure.
IPv4のSSMのための2 ^ 24のグループアドレスがあります。次の図に示すように、対応するIPv6のSSMグループアドレスを定義することができます。
-------------------------------------------------------
IPv4 Group Address IPv6 Group Address
-------------------------------------------------------
232.0.0.0/8 ff3e:0:0:0:0:0:f000:0000/96
232.255.255.255/8 ff3e:0:0:0:0:0:f0ff:ffff/96
-------------------------------------------------------
Figure 8: IVI Multicast Group Address Mapping
図8：IVIマルチキャストグループアドレスのマッピング
The source address in IPv6 MUST be IVI6(i) in order to perform Reverse Path Forwarding (RPF) as required by PIM - Sparse Mode (PIM-SM).
スパースモード（PIM-SM） - PIMによって必要とされるのIPv6ソースアドレスは、リバースパス転送（RPF）を行うためにIVI6（I）でなければなりません。
The interoperation of PIM-SM for IPv4 and IPv6 address families can either be implemented via an Application Layer Gateway or via static joins based on IGMPv3 and Multicast Listener Discovery Version 2 (MLDv2) in IPv4 and IPv6, respectively.
アプリケーション層ゲートウェイを介して、または静的介してIPv4およびIPv6アドレスファミリのPIM-SMの相互運用のいずれかで実装することができ、それぞれ、IPv4およびIPv6でのIGMPv3およびマルチキャストリスナー発見バージョン2（MLDv2の）に基づいてジョイン。
The IVI6 address has a special format (for example, IVI4=192.0.2.1/32 and IVI6=2001:db8:ffc0:2:100::/72); therefore, stateless IPv6 address autoconfiguration cannot be used. However, the IVI6 can be assigned to the IPv6 end system via manual configuration or stateful autoconfiguration via DHCPv6.
IVI6アドレス（例えば、IVI4 = 192.0.2.1 / 32とIVI6 = 2001：DB8：FFC0：2：100 :: / 72）特別なフォーマットを有します。そのため、ステートレスのIPv6アドレスの自動構成を使用することはできません。しかし、IVI6は、DHCPv6のを介して手動で設定またはステートフル自動設定を介したIPv6エンドシステムに割り当てることができます。
o For the manual configuration, the host needs to configure the IVI6 address and the corresponding prefix length, as well as the default gateway address and the DNS resolver address.
O手動設定の場合、ホストはIVI6アドレスと対応するプレフィックス長、ならびにデフォルトゲートウェイアドレスとDNSリゾルバアドレスを設定する必要があります。
o For the DHCPv6 configuration, the DHCPv6 will assign the IVI6 address and the DNS resolver address to the host. The router in the subnet should enable router advertisement (RA), since the default gateway is learned from the router.
DHCPv6設定についてはO、DHCPv6のホストにIVI6アドレスとDNSリゾルバアドレスを割り当てます。デフォルトゲートウェイがルータから学習されているため、サブネット内のルータは、ルータ広告（RA）を有効にする必要があります。
Since each IPv6 host may have multiple addresses, it is important for the host to use an IVI6(i) address to reach the global IPv4 networks. The short-term workaround is to use IVI6(i) as the default source IPv6 address of the host, defined as the policy table in [RFC3484]. The long-term solution requires that the application should be able to select the source addresses for different services.
各IPv6ホストが複数のアドレスを持っている可能性があるため、ホストがグローバルなIPv4ネットワークに到達するためにIVI6（I）アドレスを使用することが重要です。短期的な問題を回避するには、[RFC3484]のポリシーテーブルのように定義されたホストのデフォルトの送信元IPv6アドレスとしてIVI6（i）を使用することです。長期的なソリューションは、アプリケーションがさまざまなサービスのための送信元アドレスを選択できるようにする必要があることが必要です。
An implementation of IVI exists for the Linux operating system. The source code can be downloaded from [LINUX]. An example of how to configure an IVI deployment is shown in Appendix A.
IVIの実装は、Linuxオペレーティングシステムが必要です。ソースコードは、[LINUX]からダウンロードすることができます。 IVIの展開を設定する方法の例は、付録Aに示します。
The IVI DNS source code for the IVIG6(i) addresses presented in this document can be downloaded from [DNS].
この文書で提示IVIG6（I）アドレスのIVI DNSソースコードは[DNS]からダウンロードすることができます。
The IVI translator based on the Linux implementation has been deployed between [CERNET] (IPv4-only) and [CNGI-CERNET2] (IPv6-only) since March 2006. The pure-IPv6 web servers using IVI6 addresses [2001:250:ffca:2672:100::] behind the IVI translator can be accessed by the IPv4 hosts [TEST4], and also by the global IPv6 hosts [TEST6]. The pure-IPv6 clients using IVI6 addresses behind the IVI translator can access IPv4 servers on the IPv4 Internet.
250：ffca Linuxの実装に基づいて、IVIトランスレータはIVI6アドレス[2001を使用して2006年3月以降（IPv6のみ）[CERNET]（IPv4のみ）と[CNGI-CERNET2]の間の純粋な-IPv6のWebサーバーを展開してきました：2672：100 ::] IVIトランスレータの背後に、またグローバルIPv6ホスト[TEST6]でIPv4ホスト[TEST4]によってアクセスすることができます。 IVI変換器の背後IVI6アドレスを使用して、純粋な-のIPv6クライアントがIPv4インターネット上でのIPv4サーバにアクセスすることができます。
Two traceroute results are presented in Appendix B to show the address mapping of the IVI mechanism.
二つのtracerouteの結果は、IVI機構のアドレスマッピングを表示するには、付録Bに提示されています。
IVI6 manual configuration and DHCPv6 configuration of the IPv6 end system have also been tested with success.
IVI6手動設定およびIPv6のエンドシステムのDHCPv6設定にも成功してテストされています。
This document presents the prefix-specific and stateless address mapping mechanism (IVI) for the IPv4/IPv6 coexistence and transition. The IPv4 security and IPv6 security issues should be addressed by related documents of each address family and are not included in this document.
この文書は、IPv4 / IPv6の共存および移行のための接頭辞特異的およびステートレスアドレスマッピング機構（IVI）を提示します。 IPv4のセキュリティとIPv6のセキュリティ問題は、各アドレスファミリの関連文書によって対処されなければならないし、この文書に含まれていません。
However, there are several issues that need special considerations, specifically (a) IPsec and its NAT traversal, (b) DNS Security Extensions (DNSSEC), and (c) firewall filter rules.
しかし、特別な配慮を必要とするいくつかの問題、特に（a）はIPsecとそのNATトラバーサル、（b）はDNSセキュリティ拡張機能（DNSSEC）、および（c）は、ファイアウォールフィルタルールがあります。
o IPsec and its NAT traversal: Since the IVI scheme maintains end-to-end address transparency, IPsec could work with or without NAT traversal techniques.
O IPsecとそのNATトラバーサル：IVI方式は、エンドツーエンドのアドレス透明性を維持するので、IPsecはとか、NATトラバーサル技術なしで仕事ができます。
o DNSSEC: DNSSEC verification will be terminated at the IVI DNS for the "A record to AAAA record" translation. It would be fine to have a translation in a local IVI DNS server that also verifies
O DNSSEC：DNSSEC検証は翻訳「AAAAレコードにレコード」のためのIVI DNSで終了します。また、確認するローカルIVIのDNSサーバでの翻訳を持っていいと思い
DNSSEC, or in the host, if the host both translates the DNS entry and again verifies DNSSEC validity. The DNSSEC discussion is in [RFC6147].
DNSSEC、またはホストで、ホストがDNSエントリを変換し、再度、DNSSECの妥当性を検証し、両方の場合。 DNSSECの議論は[RFC6147]です。
o Firewall filter rules: Since the IVI scheme maintains the end-to-end address transparency and there is a unique mapping between IPv4 and IPv6 addresses, the firewall filter rule can therefore be implemented for one address family, or mapped to another address family and implemented in that address family. However, the current IPv6 routers may only support the access-list or uRPF (unicast Reverse Path Forwarding) for the prefix length shorter than /64; there may a practical constraint for the construction of such rules.
ファイアウォールフィルタ規則O：IVIスキームは、エンドツーエンドのアドレス透明性を維持し、IPv4アドレスとIPv6アドレスとの間の一意のマッピングがあるため、ファイアウォールのフィルタルールは、従って、一つのアドレスファミリの実装、または別のアドレスファミリにマッピングすることができそのアドレスファミリに実装されています。しかし、現在のIPv6ルータは、プレフィックス長より短い/ 64のためのアクセスリストまたはuRPFの（ユニキャストRPF）をサポートすることができます。そのようなルールを構築するための実用的な制約があってもよいです。
Except for the issues discussed above, we have not found special security problems introduced by the IVI translation in our experiments.
上述の問題を除いて、我々は我々の実験ではIVIの翻訳で導入された特別なセキュリティ問題を発見していません。
The authors would like to acknowledge the following contributors in the different phases of the IVI development: Ang Li, Yuncheng Zhu, Junxiu Lu, Yu Zhai, Wentao Shang, Weifeng Jiang, and Bizheng Fu.
アンリー、運城市朱、Junxiu呂、ゆうテキ、Wentaoシャン、微風江、およびBizhengフー：著者は、IVI開発のさまざまな段階で、次の貢献者を承認したいと思います。
The authors would like to acknowledge the following contributors, who provided helpful inputs concerning the IVI concept: Bill Manning, David Ward, Elwyn Davies, Lixia Zhang, Jun Murai, Fred Baker, Jari Arkko, Ralph Droms, Tony Hain, and Kevin Yin.
ビル・マニング、デビッド・ウォード、エルウィン・デイヴィス、Lixiaチャン、村井純、フレッド・ベイカー、ヤリArkko、ラルフDroms、トニーハイン、そしてケビン・殷：著者は、IVIの概念に関する有用入力を提供し、次の貢献者を、承認したいと思います。
The authors thank the following for funding support: the CERNET, CNGI-CERNET2, CNGI Research and Development, and the China "863" and China "973" projects.
著者は、支援に資金を提供するために次のことを感謝：CERNET、CNGI-CERNET2、CNGI研究開発、および中国の「863」と中国「973」プロジェクト。
Appendix A. The IVI Translator Configuration Example
付録A. IVI翻訳の設定例
#!/bin/bash # open forwarding echo 1 > /proc/sys/net/ipv6/conf/all/forwarding echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
＃！/ binに/ bashの番号オープンフォワーディングエコー1>は、/ proc / sys / net / IPv6の/ confに/すべて/フォワーディングエコー1>は、/ proc / sys / net / IPv4の/ confに/すべて/転送
# config route for IVI6 = 2001:db8:ffc0:2:0::/64, # IVI4 = 192.0.2.0/24
DB8：FFC0：IVI6 = 2001＃コンフィグ経路2：:: / 64 0、＃IVI4 = 192.0.2.0/24
# configure IPv6 route route add -A inet6 2001:db8:ffc0:2:0::/64 \ gw 2001:da8:aaae::206 dev eth0
＃2001 INET6 -Aを追加するIPv6ルートルートを設定：DB8：FFC0：2：0 :: / 64 \ GW 2001：DA8：aaae :: 206のdevのeth0の
# config mapping for source-PF = 2001:db8::/32 # config mapping for destination-PF = 2001:db8::/32
DB8 :: / 32＃コンフィギュレーションマッピング先-PF = 2001：DB8 :: / 32ソース-PF = 2001＃コンフィグマッピング
# for each mapping, a unique pseudo-address (10.0.0.x/8) # should be configured. # ip addr add 10.0.0.1/8 dev eth0
各マッピングのため＃、一意の疑似アドレス（10.0.0.x / 8）＃が設定されなければなりません。 ＃1のIP addrが10.0.0.1/8のdevのeth0のを追加します
# IPv4-to-IPv6 mapping: multiple mappings can be done via multiple # commands. # mroute IVI4-network IVI4-mask pseudo-address interface \ # source-PF destination-PF /root/mroute 192.0.2.0 255.255.255.0 10.0.0.1 \ eth0 2001:db8:: 2001:db8::
＃IPv4のツーIPv6のマッピング：複数のマッピングは、複数の＃コマンドを介して行うことができます。 ＃のmroute IVI4ネットワークIVI4マスク擬似アドレスインターフェイス\＃ソース-PF先-PF /ルート/のmroute 192.0.2.0 255.255.255.0 10.0.0.1 \ eth0を2001：DB8 :: 2001：DB8 ::
# IPv6-to-IPv4 mapping # mroute6 destination-PF destination-PF-pref-len /root/mroute6 2001:db8:ff00:: 40
＃IPv6のツーのIPv4マッピング＃mroute6先-PF先-PF-県-LEN /ルート/ mroute6 2001：DB8：FF00 :: 40
Figure 9: IVI Configuration Example
図9：IVIの設定例
Appendix B. The traceroute Results
付録B. tracerouteの結果
ivitraceroute 202.38.108.2
ivitraceroute 202.38.108.2
1 202.112.0.65 6 ms 2 ms 1 ms 2 202.112.53.73 4 ms 6 ms 12 ms 3 202.112.53.178 1 ms 1 ms 1 ms 4 202.112.61.242 1 ms 1 ms 1 ms 5 192.0.2.100 1 ms 1 ms 1 ms 6 192.0.2.102 1 ms 1 ms 1 ms 7 192.0.2.103 2 ms 2 ms 2 ms 8 192.0.2.104 2 ms 2 ms 2 ms 9 192.0.2.105 4 ms 4 ms 3 ms 10 202.38.108.2 2 ms 3 ms 3 ms
1 202.112.0.65 6つのMS 2、MS 1、MS 2、MS 202.112.53.73 4 6ミリ12ミリ3つの202.112.53.178 1 MS 1、MS 1、MS 1、MS 202.112.61.242 4 1ミリ5ミリ1つの192.0.2.100 1 MS 1、MS 1、MS 6つの192.0.2.102 1 MS 1、MS 1、MS 7 192.0.2.103 2ミリ秒、2ミリ秒、2ミリ秒8 192.0.2.104 2ミリ秒、2ミリ秒、2ミリ秒9 192.0.2.105 4MS 4MS 3ミリ秒、10ミリ秒202.38.108.2 2 3ミリ3ミリ
Figure 10: ivitraceroute Results
図10：ivitraceroute結果
Note that the non-IVIG6 addresses are mapped to IPv4 document address 192.0.2.0/24.
非IVIG6アドレスがIPv4文書アドレス192.0.2.0/24にマッピングされていることに注意してください。
ivitraceroute6 www.mit.edu
ivitraceroute6 www.mit.edu
src_ivi4=202.38.97.205 src_ivi6=2001:da8:ffca:2661:cd00:: dst_host=www.mit.edu dst_ip4=18.7.22.83 dst_ivig=2001:da8:ff12:716:5300::
src_ivi4 = 202.38.97.205 src_ivi6 = 2001：DA8：ffca：2661：CD00 :: dst_host = www.mit.edu dst_ip4 = 18.7.22.83 dst_ivig = 2001：DA8：FF12：716：5300 ::
traceroute to 2001:da8:ff12:716:5300:: (2001:da8:ff12:716:5300::), 30 hops max, 40 byte packets to not_ivi
2001年のtraceroute：DA8：FF12：716：5300 ::（2001：DA8：FF12：5300：716 :)、30のホップ最大、40のバイトのパケットnot_iviへ
1 2001:da8:ff0a:0:100:: 0.304 ms 0.262 ms 0.190 ms 10.0.0.1 2 2001:da8:ffca:7023:fe00:: 0.589 ms * * 202.112.35.254 3 2001:da8:ffca:7035:4900:: 1.660 ms 1.538 ms 1.905 ms 202.112.53.73 4 2001:da8:ffca:703d:9e00:: 0.371 ms 0.530 ms 0.459 ms 202.112.61.158 5 2001:da8:ffca:7035:1200:: 0.776 ms 0.704 ms 0.690 ms 202.112.53.18 6 2001:da8:ffcb:b5c2:7d00:: 89.382 ms 89.076 ms 89.240 ms 203.181.194.125 7 2001:da8:ffc0:cb74:9100:: 204.623 ms 204.685 ms 204.494 ms 192.203.116.145 8 2001:da8:ffcf:e7f0:8300:: 249.842 ms 249.945 ms 250.329 ms 207.231.240.131 9 2001:da8:ff40:391c:2d00:: 249.891 ms 249.936 ms 250.090 ms 64.57.28.45 10 2001:da8:ff40:391c:2a00:: 259.030 ms 259.110 ms 259.086 ms 64.57.28.42 11 2001:da8:ff40:391c:700:: 264.247 ms 264.399 ms 264.364 ms 64.57.28.7 12 2001:da8:ff40:391c:a00:: 271.014 ms 269.572 ms 269.692 ms 64.57.28.10 13 2001:da8:ffc0:559:dd00:: 274.300 ms 274.483 ms 274.316 ms 192.5.89.221 14 2001:da8:ffc0:559:ed00:: 274.534 ms 274.367 ms 274.517 ms 192.5.89.237 15 * * * 16 2001:da8:ff12:a800:1900:: 276.032 ms 275.876 ms 276.090 ms 18.168.0.25 17 2001:da8:ff12:716:5300:: 276.285 ms 276.370 ms 276.214 ms 18.7.22.83
1：2001 DA8：ff0a：0：100 :: 0.304ミリ秒0.262秒0.190ミリ10.0.0.1 2 2001：DA8：ffca：7023：* 202.112.35.254 3 2001 FE00 :: 0.589 MS：DA8：ffca：4900：7035 :: 1.660ミリ秒1.538秒1.905ミリ202.112.53.73 4 2001：DA8：ffca：703D：9e00 :: 0.371ミリ秒0.530秒0.459ミリ202.112.61.158 5 2001：DA8：ffca：7035：1200 :: 0.776ミリ秒0.704秒0.690ミリ202.112.53.18 6 2001：DA8：ffcb：b5c2：7d00 :: 89.382ミリ秒89.076ミリ秒89.240ミリ秒203.181.194.125 7 2001：DA8：FFC0：cb74：9100 :: 204.623 MS 204.685 204.494ミリ秒192.203.116.145 8 2001：DA8： ffcf：e7f0：8300 :: 249.842 MS 249.945 250.329ミリ秒207.231.240.131 9 2001：DA8：FF40：391c：2d00 :: 249.891 MS 249.936 250.090ミリ秒64.57.28.45 10 2001：DA8：FF40：391c：2a00 :: 259.030 MS 259.110 259.086ミリ秒64.57.28.42 11 2001：DA8：FF40：391c：700 :: 264.247 MS 264.399 264.364ミリ秒64.57.28.7 12：2001 DA8：FF40：391c：A00 :: 271.014 MS 269.572 269.692ミリ秒64.57.28.10 13：2001 DA8：FFC0：559：dd00 :: 274.300 MS 274.483 274.316ミリ秒192.5.89.221 14：2001 DA8：FFC0：559：ed00 :: 274.534 MS 274.367 274.517ミリ秒192.5.89.237 15 * * * 16：2001 DA8：FF12：A800：1900 :: 276.032 MS 275.876 276.090ミリ秒18.168.0.25 17：2001 DA8：FF12：716：5300 :: 276.285 MS 276.370 276.214ミリ秒18.7.22.83
Figure 11: ivitraceroute6 Results
図11：ivitraceroute6結果
Note that all of the IPv4 addresses can be mapped to prefix-specific IPv6 addresses (for example, 18.7.22.83 is mapped to 2001:da8:ff12: 716:5300::).
IPv4アドレスの全てはプレフィックス特定するためにIPv6アドレスをマッピングすることができることに留意されたい（例えば、18.7.22.83が2001にマッピングされる：DA8：FF12：716：5300：:)。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[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ドメインの接続"。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[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月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集計プラン"、BCP 122、RFC 4632、2006年8月。
[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月。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.
[RFC5771]綿、M.、Vegoda、L.、およびD.マイヤー、 "IPv4マルチキャストアドレス割り当てのためのIANAガイドライン"、BCP 51、RFC 5771、2010年3月。
[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の翻訳者のアドレス指定"。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]ベーカー、F.はLi、X.、バオ、C.、およびK.陰陽 "のIPv4 / IPv6変換のためのフレームワーク"、RFC 6144、2011年4月。
[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. van 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. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、サリバン、A.、マシューズ、P.、およびI.バンBeijnum、 "DNS64：IPv4のサーバーへのIPv6クライアントからのネットワークアドレス変換のためのDNS拡張機能"、RFC 6147、2011年4月。
[BEHAVE] "The IETF Behave Working Group Charter: http://datatracker.ietf.org/wg/behave/charter/".
[BEHAVE] "IETF振るまいワーキンググループ憲章：http://datatracker.ietf.org/wg/behave/charter/"。
[CERNET] "CERNET Homepage: http://www.edu.cn/english_1369/index.shtml".
[CERNET] "CERNETホームページ：http://www.edu.cn/english_1369/index.shtml"。
[CNGI-CERNET2] "CNGI-CERNET2 Homepage: http://www.cernet2.edu.cn/index_en.htm".
[CNGI-CERNET2] "CNGI-CERNET2ウェブ：http://www.cernet2.edu.cn/index_en.htm"。
[COUNT] "IPv4 address countdown: http://penrose.uk6x.com/".
[COUNT] "のIPv4アドレスのカウントダウン：http://penrose.uk6x.com/"。
[DNS] "Source Code of the IVI DNS http://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/".
[DNS] "IVI DNSのソースコードhttp://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/"。
[LINUX] "Source Code of the IVI implementation for Linux: http://linux.ivi2.org/impl/".
[LINUX] "Linux用のIVIの実装のソースコード：http://linux.ivi2.org/impl/"。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]大工、B.、 "インターネットの透明性"、RFC 2775、2000年2月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142]萩野、J.及びK.山本の "IPv6からIPv4輸送リレー翻訳"、RFC 3142、2001年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]バッタチャリヤ、S.、エド。、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
[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月。
[TEST4] "Test homepage for the IVI4(i): http://test4.ivi2.org".
【TEST4 "IVI4（I）のテストホームページ：http://test4.ivi2.org"。
[TEST6] "Test homepage for the IVI6(i): http://test6.ivi2.org", Available using IPv6 only.
[TEST6] "IVI6（I）のテストホームページ：http://test6.ivi2.org"、IPv6のみを使用して利用可能。
Authors' Addresses
著者のアドレス
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 EMail: xing@cernet.edu.cn
興李CERNETセンター/清華大学ルーム225、本館、清華大学、北京100084 CN電話：+86 10から62785983 Eメール：xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 EMail: congxiao@cernet.edu.cn
CongxiaoバオCERNETセンター/清華大学ルーム225、本館、清華大学、北京100084 CN電話：+86 10から62785983 Eメール：congxiao@cernet.edu.cn
Maoke Chen CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 EMail: fibrib@gmail.com
Maoke陳CERNETセンター/清華大学ルーム225、本館、清華大学、北京100084 CN電話：+86 10から62785983 Eメール：fibrib@gmail.com
Hong Zhang CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 EMail: neilzh@gmail.com
香港張CERNETセンター/清華大学ルーム225、本館、清華大学、北京100084 CN電話：+86 10から62785983 Eメール：neilzh@gmail.com
Jianping Wu CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 10-62785983 EMail: jianping@cernet.edu.cn
ジアンピング・ウCERNETセンター/清華大学ルーム225、本館、清華大学、北京100084 CN電話：+86 10から62785983 Eメール：jianping@cernet.edu.cn