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
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共存和过渡的中国教育研究网（CERNET）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.
本文件介绍了中国教育和研究网络（CERNET）针对IPv4/IPv6共存和过渡的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 Internet通信，也可以通过无状态转换器与全局IPv4 Internet通信。通信可以由IPv6启动，也可以由IPv4启动。IVI机制支持端到端地址透明和增量部署。IVI是部署在CERNET中的早期设计，作为有关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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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.
本文档介绍了CERNET IVI转换设计和部署，用于IPv4/IPv6共存和转换。在罗马数字中，“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是具有不同寻址结构的不同协议，因此使用不同地址族的端点之间的通信需要转换机制。有几种方法可以实现翻译。一种是无状态IP/ICMP转换算法（SIIT）[RFC2765]，它提供了一种在IPv4和IPv6数据包头（包括ICMP头）之间进行转换的机制，而不需要任何每个连接状态。但是，SIIT没有指定地址分配和路由方案[RFC2766]。例如，SIIT使用IPv4映射的IPv6地址[：：ffff:IPv4地址/96]和IPv4兼容的IPv6地址[：：IPv4地址/96]进行地址映射，但这些地址违反了IPv6路由的聚合原则[RFC4291]。另一种转换机制是网络地址转换-协议转换（NAT-PT），它具有严重的技术和操作困难；IETF已将其从拟定标准重新分类为历史状态[RFC4966]。
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. 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.translate error, please retry
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的节点可以将基于IPv6地址的引用传递给仅理解IPv4的节点。
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]
中国教育和研究网络有两个主干网，使用不同的地址族。CERNET仅为IPv4[CERNET]，CERNET2仅为IPv6[CNGI-CERNET2]，适用于IETF BEHAVE工作组定义[BEHAVE]中的“IPv6网络到IPv4互联网”和“IPv4互联网到IPv6网络”场景
[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主机。需要通过有状态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地址之间的一对一映射；因此，无法有效地使用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（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）：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 translator：基于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].
本文件中出现的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[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 Internet通信，也可以通过无状态转换器与全局IPv4 Internet通信。通信可以由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映射和转换机制在IVI转换器中实现，该转换器通过ISP的IPv4网络连接“IPv6网络”和IPv4互联网，如下图所示。
------ ----- ------
/ The \ ----- / An \ / The \
| IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 |
\Internet/ ----- \Network/ \Internet/
------ ----- ------
<===>
------ ----- ------
/ 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地址和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地址（例如，由前缀定义的/40），这是全局IPv4地址总数的映像，如下图所示。后缀为全零。
+-+-+-+-+-+-+
| IVIG4 |
+-+-+-+-+-+-+
||
\ /
\/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX | IPv4 addr | SUFFIX |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+-+-+-+-+-+-+
| 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 Internet访问，如下图所示。后缀可以是全零，也可以是将来扩展时使用的其他值。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX | |IVI4| | SUFFIX |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
\ /
\/
-+-+-+
|IVI4|
-+-+-+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 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 -> |
| 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是CERNET实现中ISP（i）的/32的前缀（例如，使用文档IPv6地址IPS6=2001:db8:：/32），位32到位39都是一个，作为IVI地址的标识符，位40到位71是嵌入的全局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
/-----\ /-----\
( 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网络，另一个到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. 路由器R1有一个IVI4（i）/k（k是IVI4（i）的前缀长度）的IPv4路由，下一跳等于192.0.2.1，该路由通过适当的聚合分布到Internet。
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具有IVIG6（i）/40的IPv6路由，下一跳等于2001:db8:：1，该路由通过适当的聚合分布到IPv6 Internet。
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/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.
注意，上述路由可以通过IVI转换器中的动态路由协议（IGP或BGP）学习/插入，与R1和R2对等。
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
-------------------------------------------------------------
-------------------------------------------------------------
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
-------------------------------------------------------------
-------------------------------------------------------------
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.
[RFC6145]中定义了IP/ICMP翻译的IETF标准，其中包含更新的技术规范。
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]中使用了校验和中立的IPv6地址。
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].
当数据包由IVI转换器翻译时，由于IPv4和IPv6报头的大小不同，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.
[RFC6145]中定义了IETF碎片和MTU处理标准，其中包含更新的技术规范。
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消息对应关系。请注意，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.
[RFC6145]中定义了IP/ICMP翻译的IETF标准，其中包含更新的技术规范。
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。然而，一些应用程序的设计使得IP地址用于识别应用层实体（例如FTP）。在这些情况下，应用层网关（ALG）是不可避免的，它可以集成到IVI转换器中。
The discussion of the use of ALGs is in [RFC6144].
[RFC6144]中讨论了ALG的使用。
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）的A记录和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（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机制可以支持协议独立多播-源特定多播（PIM-SSM）[RFC5771][RFC3569][RFC4607]的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
-------------------------------------------------------
-------------------------------------------------------
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中的源地址必须是IVI6（i），以便按照PIM-稀疏模式（PIM-SM）的要求执行反向路径转发（RPF）。
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.
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网络非常重要。短期解决方法是使用IVI6（i）作为主机的默认源IPv6地址，定义为[RFC3484]中的策略表。长期解决方案要求应用程序能够为不同的服务选择源地址。
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]下载。附录A中显示了如何配置IVI部署的示例。
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.
自2006年3月以来，基于Linux实现的IVI转换器已部署在[CERNET]（仅限IPv4）和[CNGI-CERNET2]（仅限IPv6）之间。IPv4主机[TEST4]和全局IPv6主机[TEST6]可以访问IVI转换器后面使用IVI6地址[2001:250:ffca:2672:100:：]的纯IPv6 web服务器。在IVI转换器后面使用IVI6地址的纯IPv6客户端可以访问IPv4 Internet上的IPv4服务器。
Two traceroute results are presented in Appendix B to show the address mapping of the IVI mechanism.
附录B中给出了两个跟踪路由结果，以显示IVI机制的地址映射。
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
o DNSSEC:DNSSEC验证将在IVI DNS处终止，用于“A记录到AAAA记录”的翻译。在本地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（单播反向路径转发）；在制定此类规则时可能存在实际限制。
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、朱运城、陆俊秀、于斋、尚文涛、蒋玮峰和毕正富。
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概念的有用信息：Bill Manning、David Ward、Elwyn Davies、Lixia Zhang、Jun Murai、Fred Baker、Jari Arkko、Ralph Droms、Tony Hain和Kevin Yin。
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
#!/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
# 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
# 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
# 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
# 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
# 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/root/mroute 192.0.2.0 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-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
IVI追踪路线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 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 6 192.0.2.102 1 ms 1 ms 7 192.0.2.103 2 ms 2 ms 8 192.0.2.104 2 ms 2 ms 9 192.0.2.105 4 ms 3 ms 10 202.38.108.2 ms 3 ms 3 ms
Figure 10: ivitraceroute Results
图10:IVITracerote结果
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
第6页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
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
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:6结果
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 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准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，“互联网协议，第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）”，RFC2765，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云连接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 42912006年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 43802006年2月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，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 52142008年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 57712010年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转换器的IPv6寻址”，RFC 6052010年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 61442011年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 61452011年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，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年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 61472011年4月。
[BEHAVE] "The IETF Behave Working Group Charter: http://datatracker.ietf.org/wg/behave/charter/".
[BEHAVE]“IETF BEHAVE工作组章程：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/".
[计数]“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]Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142]Hagino，J.和K.Yamamoto，“IPv6到IPv4传输中继转换器”，RFC3142，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.，编辑，“源特定多播（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
兴利赛尔网中心/清华大学北京清华大学主楼225室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
聪晓宝CERNET中心/清华大学北京清华大学主楼225室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
陈茂科CERNET中心/清华大学北京清华大学主楼225室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
张虹CERNET中心/清华大学北京清华大学主楼225室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
吴建平CERNET中心/清华大学北京清华大学主楼225室100084 CN电话：+86 10-62785983电子邮件：jianping@cernet.edu.cn