[要約] RFC 6219は、中国の教育・研究ネットワーク（CERNET）におけるIPv4/IPv6の共存と移行のためのIVIトランスレーションの設計と展開に関するものです。このRFCの目的は、CERNETにおけるIPv4とIPv6のトランスレーション機能の設計と展開に関するガイドラインを提供することです。
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
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は、「IPv4インターネットへのIPv6ネットワーク」および「IPv4インターネットからIPv6ネットワークへのIPv4インターネット」シナリオのプレフィックス固有のステートレスアドレスマッピングメカニズムです。IVI設計では、ISPのIPv4アドレスのサブセットはISPのIPv6アドレスに埋め込まれているため、これらのIPv6アドレスを使用するホストはグローバルIPv6インターネットと直接通信でき、ステートレストランスレーターを介してグローバルIPv4インターネットと通信できます。通信は、IPv6を開始するか、IPv4を開始することができます。IVIメカニズムは、エンドツーエンドのアドレスの透明性と増分展開をサポートします。IVIは、IPv4/IPv6ステートレス翻訳に関するIETF標準ドキュメントの参照として、セルネに展開された初期の設計です。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6219.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. 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の共存と遷移のセルネ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島をリンクできますが、2つの異なるアドレスファミリ[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は異なるアドレス指定構造を持つ異なるプロトコルであるため、異なるアドレスファミリを使用したエンドポイント間の通信には翻訳メカニズムが必要です。翻訳を実装する方法はいくつかあります。1つは、ステートレスIP/ ICMP翻訳アルゴリズム（SIIT）[RFC2765]です。これは、接続ごとの状態を必要とせずにIPv4とIPv6パケットヘッダー（ICMPヘッダーを含む）間の翻訳のメカニズムを提供します。ただし、SIITはアドレスの割り当ておよびルーティングスキーム[RFC2766]を指定していません。たとえば、SIITはIPv4-Mapped IPv6アドレスを使用します[:: FFFF：IPv4-ADDR/96]およびIPv4互換IPv6アドレス[:: IPv4-Address/96]をアドレスマッピングに使用しますが、これらのアドレスはIPv6の集約原理に違反しますルーティング[RFC4291]。もう1つの翻訳メカニズムは、ネットワークアドレス翻訳 - プロトコル翻訳（NAT -PT）です。IETFは、提案された基準から歴史的ステータスへの再分類[RFC4966]です。
In order to solve the technical difficulties in NAT-PT, the issues and the possible workarounds are: 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.
NAT-PTの技術的な困難を解決するために、問題と可能な回避策は次のとおりです。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.
4. ヘッダーとプロトコルのIPv4バージョンとIPv6バージョンの間の互換性のないセマンティクスによる情報の喪失が発生する可能性があります。これに対する部分的な治療法は、たとえば、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はIPv4-Only [Cernet]、Cernet2はIPv6のみ[CNGI-Cernet2]であり、「IPv4インターネットへのIPv6ネットワーク」および「IPv4インターネットへのIPv4ネットワークへのIPv4インターネット」シナリオに適合しています。定義[行動]
[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ルーティングの練習に従う必要があります。
3. It should be able to be deployed incrementally.
3. 徐々に展開できるはずです。
4. It should be able to use IPv4 addresses effectively due to the IPv4 address depletion problem.
4. IPv4アドレスの枯渇問題により、IPv4アドレスを効果的に使用できるはずです。
5. It should be stateless to achieve scalability.
5. スケーラビリティを実現するには、ステートレスである必要があります。
6. The DNS function should be decoupled from the translator.
6. DNS関数は、翻訳者から分離する必要があります。
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 Autoconfigurationを使用することはできません。Stateful 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. ペイロードにアドレスを埋め込んだアプリケーションには、アルグが必要です。
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は、ステートレス翻訳のためにセルネに展開された初期の設計です。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（I）のIPv6ホストによって使用されます。
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）：IPVIマッピングメカニズムを介したIPv6アドレスファミリーのIPS6（I）のサブセットと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）：IVIG6（I）のサブセットとIVIマッピングメカニズムを介してIVI4（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].
「必須」、「必要」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうは思わない」、「そうでない」、「推奨」、「5月」、「オプション」が表示されるとき、このドキュメントでは、[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：シナリオ：「IPv4インターネットへのIPv6ネットワーク」および「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アドレスとIPv4のIPv6アドレスを表す必要があります。
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アドレスブロック（通常はA /32）のごく一部があります。次の図に示すように、IPv6アドレス（たとえば、Prefixで定義された /40）は、グローバルIPv4アドレスの全体の画像です。接尾辞はすべてゼロです。
+-+-+-+-+-+-+
| 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.
ここで、ビット0からビット31は、セルネの実装でISP（i）s /32（例えば、ドキュメントIPv6アドレスIPS6 = 2001：db8 :: /32を使用する）のプレフィックスです。IVIアドレスの識別子、およびビット40からビット71は、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は、IPv4ネットワークの2つのインターフェイスを備えた特別なデュアルスタックルーターで、もう1つはIPv6ネットワークにあります（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. Router R1にはIVI4（I）/K（KはIVI4（I）のプレフィックス長）のIPv4ルートがあり、次のホップは192.0.2.1に等しく、このルートは適切な集約でインターネットに分散されます。
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. Router R2には、IVIG6（I）/40のIPv6ルートがあり、次のホップは2001年に等しい：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.
4. IVI翻訳者には、IVI6（I）/（40 K）のIPv6ルートがあり、次のホップは2001年に等しい：DB8 :: 2に等しくなります。IVI翻訳者には、IPv4デフォルトルート0.0.0/0もあり、次のホップは192.0.2.2に等しくなります。
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-to-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-to-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ヘッダーを含むチェックサムで構成されているため、輸送層ヘッダーの再計算と更新を実行する必要があります。SIITは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パケットはIVI4パケットよりも少なくとも20バイト大きくなり、IPv6ネットワークの次のリンクのMTUを超える可能性があります。。したがって、IPv6断片化ヘッダーとIPv4ヘッダーのフラグメンテーションフィールド間の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.
IPv4とIPv6の間のICMPメッセージ変換の場合、IVIはSIIT [RFC2765]で定義されているICMP/ICMPV6メッセージ対応に従います。IPvig6（I）に属していない中間ルーターによってICMPメッセージが生成される可能性があることに注意してください。ICMPの翻訳はPATH MTUの発見とトラブルシューティングにとって重要であるため、ICMPパケットの非IVIG6アドレスのIPv4表現が必要です。現在のIVIプロトタイプでは、小さなIPv4アドレスブロックを使用して、非IVIG6アドレスを識別します。これにより、翻訳されたICMPメッセージが不明またはプライベートIPソースのために破棄されるのを防ぎます。
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、Secure Shell（SSH）、Telnetなどの既存のアプリケーションのほとんどをサポートできます。ただし、一部のアプリケーションは、アプリケーション層エンティティ（FTPなど）を識別するためにIPアドレスを使用するように設計されています。これらの場合、アプリケーションレイヤーゲートウェイ（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サービスを提供するために、各ホスト名にはAレコードとAAAAレコードの両方がそれぞれIVI4（I）とIVI6（I）を指します。同じ名前は常に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（i）ホストがIPv4のみのドメイン名のAAAAレコードをクエリすると、IVI DNSは最初にAAAAレコードを照会します。AAAAレコードが存在しない場合、IVI DNSはAレコードを照会し、IVIG6（i）にマッピングし、AAAAレコードをIVI6（i）ホストに返します。このプロセスの技術仕様は[RFC6147]で定義されています。
The IVI mechanism can support IPv4/IPv6 communication of Protocol Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC5771] [RFC3569] [RFC4607].
IVIメカニズムは、プロトコル独立マルチキャストのIPv4/IPv6通信 - ソース固有のマルチキャスト（PIM-SSM）[RFC5771] [RFC3569] [RFC4607]をサポートできます。
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.
IPv4SSMには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).
IPv6のソースアドレスは、PIM -SPARSEモード（PIM -SM）で要求されるリバースパス転送（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）;したがって、Stateless IPv6アドレスAutoconfigurationを使用できません。ただし、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.
o DHCPV6構成の場合、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ホストには複数のアドレスがある可能性があるため、ホストがIVI6（I）アドレスを使用してグローバルIPv4ネットワークに到達することが重要です。短期的な回避策は、[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.
LinuxオペレーティングシステムにはIVIの実装が存在します。ソースコードは[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.
Linux実装に基づいたIVI翻訳者は、2006年3月以来[CERNET]（IPv4-Only）と[CNGI-Cernet2]（IPv6-only）の間に展開されています。IVI6アドレスを使用したPure-IPV6 Webサーバー[2001：250：FFCA：2672：100 ::] IVI翻訳者の後ろには、IPv4ホスト[TEST4]、およびグローバルIPv6ホスト[TEST6]によってアクセスできます。IVI6アドレスを使用するPure-IPV6クライアントは、IVI翻訳者の背後にあるアドレス指定で、IPv4インターネット上のIPv4サーバーにアクセスできます。
Two traceroute results are presented in Appendix B to show the address mapping of the IVI mechanism.
IVIメカニズムのアドレスマッピングを示すために、付録Bに2つのTraceroute結果が表示されます。
IVI6 manual configuration and DHCPv6 configuration of the IPv6 end system have also been tested with success.
IPv6エンドシステムのIVI6マニュアル構成と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 DNSSEC, or in the host, if the host both translates the DNS entry and again verifies DNSSEC validity. The DNSSEC discussion is in [RFC6147].
o DNSSEC：DNSSECの検証は、「A Record to AAAA Record」翻訳のIVI DNSで終了します。ホストがDNSエントリを翻訳し、DNSSECの有効性を再度検証する場合、DNSSECを検証するローカルIVI DNSサーバーまたはホストに翻訳を用意することは問題ありません。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アドレスの間に一意のマッピングがあるため、ファイアウォールフィルタールールを1つのアドレスファミリに実装するか、別のアドレスファミリにマッピングして実装できます。その住所家族。ただし、現在のIPv6ルーターは、 /64より短いプレフィックス長のアクセスリストまたはURPF（ユニキャストリバースパス転送）のみをサポートできます。そのような規則の構築には実際的な制約があるかもしれません。
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.
著者は、IVI開発のさまざまな段階で次の貢献者を認めたいと考えています：Ang Li、Yuncheng Zhu、Junxiu Lu、Yu Zhai、Wentao Shang、Weifeng Jiang、およびBizheng Fu。
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.
著者は、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」プロジェクト。
#!/bin/bash
# open forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
# config route for IVI6 = 2001:db8:ffc0:2:0::/64,
# 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
# config mapping for source-PF = 2001:db8::/32
# config mapping for destination-PF = 2001:db8::/32
# 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）＃を構成する必要があります。＃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-to-IPV6マッピング：複数のマッピングを複数の＃コマンドで実行できます。＃mroute ivi4-network ivi4-mask pseudo-address interface \＃source-pf destination-pf /roote 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
Figure 9: IVI Configuration Example
図9：IVI構成の例
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 1 MS 2 202.112.53.73 4 MS 6 MS 12 MS 12 MS 3 202.112.53.178 1 MS 1 MS 1 MS 1 MS 1 MS 4 202.112.61.2426 192.0.2.102 1 MS 1 MS 1 MS 1 MS 7 192.0.2.103 2 MS 2 MS 2 MS 2 MS 8 192.0.2.2.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 3 MS MS
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 = 2001：da8：ffca：2661：cd00 :: dst_host = www.mit.edu dst_ip4 = 18.7.22.83 dst_ivig = 2001：da8：ff12：716：5300：:: 716：5300 ：:
traceroute to 2001:da8:ff12:716:5300:: (2001:da8:ff12:716:5300::),
30 hops max, 40 byte packets to 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
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] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス変換 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「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：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「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] Fuller、V。およびT. Li、「クラスレス間ドメインルーティング（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] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（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] Cotton、M.、Vegoda、L。、およびD. Meyer、「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] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M.、およびX. Li、「IPv4/IPv6翻訳者のアドレス指定」、RFC 6052、2010年10月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4/IPv6翻訳のフレームワーク」、RFC 6144、2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP/ICMP翻訳アルゴリズム」、RFC 6145、2011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. Van Beijnum、「Stateful Nat64：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳」、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.、Sullivan、A.、Matthews、P。、およびI. Van Beijnum、 "DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のDNS拡張"、RFC 6147、2011年4月。
[BEHAVE] "The IETF Behave Working Group Charter: http://datatracker.ietf.org/wg/behave/charter/".
[beave] "IETFはワーキンググループチャーター：http：//datatracker.ietf.org/wg/behave/charter/」。
[CERNET] "CERNET Homepage: http://www.edu.cn/english_1369/index.shtml".
[Cernet] "Cernet Homepage：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] Hagino、J。およびK. Yamamoto、「IPv6-to-IPV4 Transport Relay Translator」、RFC 3142、2001年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S.、ed。、「ソース固有のマルチキャスト（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] AOUN、C。およびE. Davies、「ネットワークアドレス翻訳者を移動する理由 - プロトコル翻訳者（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
Xing Li Cernet Center/Tsinghua University Room 225、メインビル、Tsinghua University Beijing 100084 CN電話：86 10-62785983メール：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 Bao Cernet Center/Tsinghua University Room 225、メインビルディング、Tsinghua University Beijing 100084 CN電話：86 10-62785983電子メール：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 Chen Cernet Center/Tsinghua University Room 225、メインビルディング、Tsinghua University Beijing 100084 CN電話：86 10-62785983メール：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
Hong Zhang Cernet Center/Tsinghua University Room 225、メインビルディング、Tsinghua University Beijing 100084 CN電話：86 10-62785983メール：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
Jianping Wu Cernet Center/Tsinghua University Room 225、メインビルディング、Tsinghua University Beijing 100084 CN電話：86 10-62785983メール：jianping@cernet.edu.cn