Network Working Group X. Li
Internet-Draft M. Chen
Intended status: Informational C. Bao
Expires: August 13, 2009 H. Zhang
J. Wu
CERNET Center/Tsinghua University
February 9, 2009
Prefix-specific and Stateless Address Mapping (IVI) for IPv4/IPv6
Coexistence and Transition
draft-xli-behave-ivi-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Li, et al. Expires August 13, 2009 [Page 1]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
Abstract
This document presents the concept and practice of the prefix-
specific and stateless address mapping mechanism (IVI) for IPv4/IPv6
coexistence and transition. In this scheme, subsets of the IPv4
addresses are embedded in prefix-specific IPv6 addresses and these
IPv6 addresses can therefore communicate with the global IPv6
networks directly and can communicate with the global IPv4 networks
via stateless gateways. The IVI scheme supports the end-to-end
address transparency and incremental deployment. This document is a
comprehensive report on the IVI design and its deployment in large
scale public networks.
Version 01 of the IVI document is a simplified version of version 00
to present the main concepts and recent practice of the IVI
translation scheme.
Li, et al. Expires August 13, 2009 [Page 2]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5
3. The IVI Translation Algorithm . . . . . . . . . . . . . . . . 6
3.1. Address Mapping . . . . . . . . . . . . . . . . . . . . . 6
3.2. Routing and Forwarding . . . . . . . . . . . . . . . . . . 8
3.3. Network-layer Header Translation . . . . . . . . . . . . . 9
3.4. Transport-layer Header Translation . . . . . . . . . . . . 10
3.5. Fragmentation and MTU Handling . . . . . . . . . . . . . . 11
3.6. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . 11
3.7. Application Layer Gateway . . . . . . . . . . . . . . . . 11
4. The IVI DNS Configuration . . . . . . . . . . . . . . . . . . 11
4.1. DNS Configuration for the IVI6(i) Addresses . . . . . . . 11
4.2. DNS Configuration for the IVIG46(i) Addresses . . . . . . 12
5. The Advanced IVI translation Algorithm . . . . . . . . . . . . 12
5.1. IPv4 Address Multiplexing . . . . . . . . . . . . . . . . 12
5.2. IVI NAT464 . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. IVI Multicast . . . . . . . . . . . . . . . . . . . . . . 13
6. IVI Host Operation . . . . . . . . . . . . . . . . . . . . . . 13
6.1. IVI Address Assignment . . . . . . . . . . . . . . . . . . 13
6.2. IPv6 Source Address Selection . . . . . . . . . . . . . . 14
7. The IVI Implementation . . . . . . . . . . . . . . . . . . . . 14
7.1. Linux Implementation . . . . . . . . . . . . . . . . . . . 14
7.2. Testing Environment . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Appendix A. The IVI gateway configuration example . . . . . . 16
13. Appendix B. The traceroute results . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Li, et al. Expires August 13, 2009 [Page 3]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
1. Introduction
This document presents the concept and practice of the prefix-
specific and stateless address mapping mechanism (IVI) for IPv4/IPv6
coexistence and transition.
The experiences for the IPv6 deployment in the past 10 years strongly
indicate that for a successful transition, the IPv6 hosts need to
communicate with the global IPv4 networks [JJI07]. 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 the IPv4 address depletion problem makes
the dual-stack approach inapplicable [COUNT]. The tunneled
architectures can link the IPv6 islands cross IPv4 networks, but they
cannot help the communication between two address families [RFC3056]
[RFC5214] [RFC4380]. The translation architectures can relay the
communications for the hosts located in IPv4 and IPv6 networks, but
the current implementation of this kind of architecture is not
scalable and it cannot maintain the end-to-end address transparency
[RFC2766] [RFC3142] [RFC4966] [RFC2775].
However, since IPv4 and IPv6 are different protocols with different
addressing structure, the translation mechanism is still necessary
for the communication between the two address families. There are
several ways to implement the translation. One is the stateless IP/
ICMP translation algorithm (SIIT), which provides a mechanism for the
translation between IPv4 and IPv6 packet headers (including ICMP
headers) without requiring any per-connection state. But, SIIT does
not specify the address assignment and routing scheme [RFC2766]. For
example, when SIIT is used for the IPv4 mapped IPv6 addresses
[::FFFF:ipv4-addr/96] and IPv4 compatible IPv6 addresses [::ipv4-
address/96]), these addresses violate the aggregation nature of the
IPv6 routing [RFC4291]. The other translation mechanism is NAT-PT,
which has serious technical and operational difficulties and IETF has
reclassified it from proposed standard to historic status. But in
the same document, it suggested that a revised, possibly restricted
version of NAT-PT can be a suitable solution for the communication
between IPv4 and IPv6 hosts [RFC4966]. Recently, several mechanisms
are proposed in this direction, for example NAT64 translates the IPv4
server address by adding or removing a /96 prefix, and translates the
IPv6 client address by installing mappings in the normal NAT manner
[I-D.bagnulo-behave-nat64].
In this document, we follow the basic specification of SIIT, but we
define the address assignment and routing scheme (IVI). Our IVI
mechanism is related to SIIT and NAT-PT, but differs from them
significantly. First, it is stateless in both the IPv4-to-IPv6
mapping direction, as well as in the IPv6-to-IPv4 mapping direction.
Li, et al. Expires August 13, 2009 [Page 4]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
Secondly, it supports address transparency. Thirdly, it supports
both client-server applications and the peer-to-peer applications
cross IPv4 and IPv6 address families without using NAT-traversal
techniques. Finally, it can satisfy most of the basic and advanced
requirements for the IPv4 to IPv4 transition as specified by the
Internet Drafts [I-D.v6ops-nat64-pb-statement-req].
2. Terms and Abbreviations
The following terms and abbreviations are used in this document:
IVI: IV means 4 and VI means 6 in Roman representation, so IVI means
mapping and translation between IPv4 and IPv6.
ISP(i): A specific Internet service provider "i".
IPG4: An address set containing all IPv4 addresses, the addresses in
this set are mainly used by IPv4 hosts at the current stage.
IPS4(i): A subset of IPG4 allocated to ISP(i).
IVI4(i): A subset of IPS4(i), the addresses in this set will be
mapped to IPv6 via IVI rule and physically used by IPv6 hosts of
ISP(i).
IPG6: An address set containing all IPv6 addresses.
IPS6(i): A subset of IPG6 allocated to ISP(i).
IVIG46(i): A subset of IPS6(i), an image of IPG4 in IPv6 address
family via IVI mapping rule.
IVI6(i): A subset of IVIG46(i), an image of IVI4(i) in IPv6 address
family via IVI mapping rule.
IVI gateway: The mapping and translation gateway between IPv4 and
IPv6 based on IVI scheme.
IVI DNS: Providing IVI Domain Name Service (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].
Li, et al. Expires August 13, 2009 [Page 5]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
3. The IVI Translation Algorithm
The IVI is a prefix-specific and stateless address mapping scheme
which can be carried out by individual ISPs. This is to say a subset
of the ISPs IPv6 network can communicate with the IPv4 Internet and
the IPv4 Internet can communicate with the subset of the ISPs IPv6
network
IVI mapping and translation mechanism is implemented in an IVI
gateway which connects to both the ISP's IPv4 and IPv6 networks. The
IP header and ICMP header translation algorithms similar to the ones
in SIIT are implemented in the IVI gateway [RFC2765].
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, which is the image of the totality
of the global IPv4 addresses.
Each provider can borrow a portion of its IPv4 addresses and maps
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.
The packets generated from the global IPv4 addresses and sent to IVI4
(the IPv4 image of the special IPv6 addresses) are routed to the IPv4
interface of the IVI gateway via the IPv4 routing protocol and the
packets generated from the special IPv6 addresses and sent to IPG46
(the image of the global IPv4 addresses) are routed to the IPv6
interface of the IVI gateway via the IPv6 routing protocol. The
processes in both directions are symmetric. In addition, the special
IPv6 addresses can communicate with the global IPv6 networks.
The IVI scheme related issues, for example the IVI DNS, the IPv4
addresses multiplexing, the IVI multicast, etc. can be solved without
involving any major change in the current Internet protocol.
3.1. Address Mapping
The IVI address mapping is defined based on individual ISP's prefix
as shown in the following figure.
Li, et al. Expires August 13, 2009 [Page 6]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
| 0 |32 |40 |72 127|
------------------------------------------------------------------
| |FF | | |
------------------------------------------------------------------
|<- IPv6 prefix ->| |<- IPv4 address ->|<- zero padding ->|
Figure 1: IVI Address Mapping
where bit 0 to bit 31 are the prefix of ISP(i)'s /32 (e.g.
IPS6=2001:DB8::/32), bit 32 to bit 39 are all one's as the identifier
of IVI, bit 40 to bit 71 are embedded global IPv4 space (IPG4)
presented in hexadecimal format. (e.g. 2001:DB8:ff00::/40). Because
this mapping is 1-to-1 defined by the IVI mapping rule, it is
stateless and it has feature of end-to-end address transparency.
(1) The ISP(i) uses a subset of ISP4(i) defined as IVI4(i), and maps
it into IPv6 as IVI6(i). The IVI6(i) is physically used by IPv6
hosts inside ISP(i)'s IPv6 network and the IVI4(i) cannot be used by
IPv4 hosts. Therefore, IVI6(i) is the special IPv6 address block
which can communicate with both address families.
(2) Based on the above mapping rule, the ISP(i) uses a subset of
ISP6(i) defined as IVIG46(i), and maps it into IPv4 as IPG4. The
IVIG46(i) is virtually used by global IPv4 hosts and it cannot be
used by IPv6 hosts, except the portion of IVI6(i).
The mapping of the different address sets and the relations are shown
in the following figure.
|<-------IPG4--------------------->|
| |<----IPS4(i)----->| |
| |<-IVI4(i)->| |
| | | |
| | /\ | |
| | || | |
| | mapping | |
| | || | |
| | \/ | |
| | | |
| |<-IVI6(i)->| |
|<------IPG46(i)------------------>|
|<--------IPS6(i)------------------------------>|
|<-----------IPG6-------------------------------------------->|
Li, et al. Expires August 13, 2009 [Page 7]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
Figure 2: IVI Address Mapping Relation
The address reachability matrix of the IPv4, IVI, non-IVI and IPv6 is
shown in the following figure.
IPG4 IVI non-IVI IPG6
---------------------------------------
IPG4 | OK OK NO NO
IVI | OK OK OK OK
non-IVI | NO OK OK OK
IPG6 | NO OK OK OK
Figure 3: IVI Reachability Matrix
where IVI4(i) and IVI6(i) are representing the same entities in IPv4
and IPv6 address families, respectively. Similarly, IPG4 and
IVIG46(i) are representing the same entities in IPv4 and IPv6 address
families, respectively. In addition, IVI4(i) is a subset of IPG4 and
IVI6(i) is a subset of IVIG46(i).
In addition, depending on the implementation scope of the IVI
gateway, IVIG46(i) block can also be defined as 2001:DB8:FFFF::/48,
2001:DB8:ABCD:FF00::/56 or 2001:DB8:ABCD:FFFF::/64, etc. A special
case is to define IVIG46(i)=2001:DB8:XXXX:XXXX:XXXX:XXXX::/96, then
the mapping rule is similar to the method of translating the IPv4
server address proposed in [I-D.bagnulo-behave-nat64].
3.2. Routing and Forwarding
Based on the IVI address mapping rule, the routing is
straightforward, as shown in the following figure.
/-----\ /-----\
(ISP's ) ----192.168.1.2 ------------- 2001:DB8::2---- (ISP's )
(IPv4 )--|R1|-------------|IVI gateway|------------|R2|---(IPv6 )
(network) ---- 192.168.1.1-------------2001:DB8::1 ---- (network)
\-----/ \-----/
Figure 4: IVI Routing
where
(1) Router R1 has IPv4 route of IVI4(i)/k (k is the prefix length of
Li, et al. Expires August 13, 2009 [Page 8]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
IVI4(i)) with next-hop equals to 192.168.1.1 and this route is
distributed to global IPv4 networks with proper aggregation.
(2) Router R2 has IPv6 route of IVIG46(i)/40 with next-hop equals to
2001:DB8::1 and this route is distributed to global IPv6 networks
with proper aggregation.
(3) IVI gateway has IPv6 route of IVI6(i)/(40+k) with next hop equals
to 2001:DB8::2. IVI gateway also has IPv4 default route 0.0.0.0/0
with next hop equals to 192.168.1.2 .
Note that the routes described above can be learned/inserted by
dynamic routing protocols in the IVI gateway neighboring (IGP) or
peering (BGP) with R1 and R2.
Since both IVI4(i) and IVI6(i) are aggregated to IPS4(i) and IPS6(i)
in ISP(i)'s border routers respectively, there will be no affect to
the global IPv4 and IPv6 routing tables [RFC4632].
Since IVI gateway is stateless, it can support multi-homing when same
prefix is used.
Since IVI can be implemented independently in each ISP's network, it
can be incrementally deployed.
3.3. Network-layer Header Translation
IPv4 [RFC791] [RFC0791] and IPv6 [RFC2460] are different protocols
with different network layer header format, the translation of the
IPv4 and IPv6 headers must be performed [MVB98] [RFC2765] as shown in
the following figures.
Li, et al. Expires August 13, 2009 [Page 9]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
-------------------------------------------------------------
IPv4 Field Translated to IPv6
-------------------------------------------------------------
Version (0x4) Version (0x6)
IHL discarded
Type of Service discarded
Total Length Payload Length = Total Length -IHL * 4
Identification discarded
Flags discarded
Offset discarded
Time to Live Hop Limit
Protocol Next Header
Header Checksum discarded
Source Address IVI address mapping
Destination Address IVI address mapping
Options discarded
-------------------------------------------------------------
Figure 5: IPv4 to IPv6 Header translation based on IVI scheme
-------------------------------------------------------------
IPv6 Field Translated to IPv4 Header
-------------------------------------------------------------
Version (0x6) Version (0x4)
Traffic Class discarded
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 6: IPv6 to IPv4 Header translation based on IVI scheme
3.4. Transport-layer Header Translation
Since the TCP and UDP headers [RFC0793] [RFC0768] consist of check
sums which include the IP header, the recalculation and updating of
the transport-layer headers MUST be performed [RFC2765].
Li, et al. Expires August 13, 2009 [Page 10]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
3.5. Fragmentation and MTU Handling
When the packet is translated by the IVI gateway, 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
fragmentation field in the IPv4 headers are necessary, which is
performed in the IVI gateway according to SIIT [RFC2765].
3.6. ICMP Handling
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 IVIG46(i). Since ICMP
translation is important to the path MTU discovery, the inverse
mapping for unmapped addresses is defined in this document. In the
current prototype, a pseudo IPv4 address is generated. This prevents
translated ICMP messages from being discarded due to unknown or
private IP source. A small IPv4 address block should be reserved to
identify the non-IVI mapped IPv6 addresses.
3.7. Application Layer Gateway
Due to the features of 1-to-1 address mapping and stateless, IVI can
support most of the existing applications, such as HTTP, SSH, Telnet
and Microsoft Remote Desktop Protocol. However, some applications
are designed such that IP addresses are used to identify application-
layer entities (e.g. FTP). In these cases, application layer
gateway (ALG) is unavoidable, but it can be integrated into the IVI
gateway.
4. The IVI DNS Configuration
The DNS [RFC1035] service is important for the IVI scheme.
4.1. DNS Configuration for the IVI6(i) Addresses
For providing authoritative DNS service for IVI4(i) and IVI6(i), each
host name will both have an A record and an 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 gateway.
Li, et al. Expires August 13, 2009 [Page 11]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
4.2. DNS Configuration for the IVIG46(i) Addresses
For resolving the IVI IPv6-mapped global IPv4 space (IVIG46(i)), each
ISP must provide customized IVI DNS service for the IVI6(i) hosts.
The IVI DNS server is in dual stack environment. When the IVI6(i)
host queries an AAAA record for an IPv4 only domain name, the IVI DNS
server will query the A record and map it to IVIG46(i) with ISP's
IPv6 prefix and return an AAAA record to the IVI6(i) host.
5. The Advanced IVI translation Algorithm
5.1. IPv4 Address Multiplexing
Since public-IPv4 address is a scarce resource, the effective use of
the IPv4 address is important for the IVI scheme. The multiplexing
techniques are temporal multiplexing and transport port multiplexing.
The IVI6 can be temporally multiplexed inside the ISP(i)'s /32. This
is to say that the ISP can dynamically assign IVI6(i) to an end
system when it requests the IPv4 communication service and release
the IVI6(i) when the communication is finished. For temporal
multiplexing, the features of stateless and end-to-end address
transparency are maintained.
To further increase the utilization ratio of the public IPv4
addresses, the port multiplexing inside the ISP(i)'s /32 can be
deployed [RFC2766] [RFC4966]. This is to say that a single IPv4
address (IVI4(i)) can be used for multiple IVI6(i) addresses. The
mapping scheme is to use the least significant bits in the IVI6(i) to
define the multiple mapping and combine the transport-layer port
number to perform uniquely the mapping from IVI4(i) to IVI6(i).
5.2. IVI NAT464
The IVI scheme can support the IPv4 over IPv6 service (NAT464), i.e.
a stub IPv4 network can be connected to an IVI gateway to reach the
IPv6 network and via another IVI gateway to reach the global IPv4
network [RFC4925]
A more interesting scenario is to integrate the functions of the
first IVI gateway into the end-system. In this case, the application
softwares are IPv4-based and there is no need to have ALG support in
the IVI gateway when it is communicating with IPv4 hosts.
Li, et al. Expires August 13, 2009 [Page 12]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
5.3. IVI Multicast
The IVI scheme can support IPv4/IPv6 communication of the protocol-
independent specific-source sparse-mode multicast (PIM SSM) [RFC3171]
[RFC3569] [RFC4607].
(1) The IVI group address mapping rule: 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 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 7: IVI Multicast Group Address Mapping
(2) The IVI multicast source address selection: The source address in
IPv6 has to be IVI6(i) in order to perform reverse path forwarding
(RPF) as required by PIM-SM.
(3) The multicast protocol: The inter operation of PIM-SM for address
families IPv4 and IPv6 can either be implemented via the application
layer gateway or via the static join based on IGMPv3 and MLDv2 in
IPv4 and IPv6, respectively.
The Any Source Multicast (ASM) cannot be supported in the cross
address-family environment, since IPv6 does not support the MSDP
[RFC4611], and IPv4 does not support the embedded RP [RFC3956].
6. IVI Host Operation
6.1. IVI Address Assignment
The IVI6 address has special format (for example IVI4=202.38.114.1/32
and IVI6=2001:250:ffca:2672:0100::0/72), therefore, the stateless
IPv6 address autoconfiguration cannot be used. However, the IVI6 can
be assigned to the IPv6 end system via manual configuration. It is
also possible to do stateful autoconfiguration via DHCPv6.
Li, et al. Expires August 13, 2009 [Page 13]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
6.2. IPv6 Source Address Selection
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 work around is to use IVI6(i) as the default IPv6
address of the host. The long-term solution requires that the
application be able to select the source addresses for different
services.
7. The IVI Implementation
7.1. Linux Implementation
The IVI translation algorithm presented in this document is
implemented in the Linux OS and the source code can be downloaded
[LINUX]. The example of the configuration is shown in Appendix A.
The IVI DNS Configuration for the IVIG46(i) Addresses presented in
this document can be downloaded [DNS].
7.2. Testing Environment
The IVI gateway based on the Linux implementation has been deployed
between [CERNET] (IPv4 and partially dual-stack) and [CNGI-CERNET2]
(pure IPv6) since March 2006. The pure IPv6 web servers using IPv6
addresses (IVI) behind IVI gateway can be accessed by the IPv4 hosts
[IVI4], and also by the global IPv6 hosts [IVI6].
Two traceroute results are presented in Appendix B to show the
address mapping of the IVI scheme.
The IVI6 manual configuration and the DHCPv6 configuration of the
IPv6 end system have also been tested with success.
8. Security Considerations
This document presents the prefix-specific and stateless address
mapping scheme (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.
However, the specific security issues for the IVI gateway
implementation should be studied and addressed during the development
of the IVI mechanisms.
Li, et al. Expires August 13, 2009 [Page 14]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
9. IANA Considerations
This memo adds no new IANA considerations.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
10. Contributors
The authors would like to acknowledge the following contributors in
the different phases of the IVI development: Ang Li, Yuncheng Zhu,
Junxiu Lu and Yu Zhai.
The authors would like to acknowledge the following contributors who
provided helpful inputs concerning the IVI concept: Bill Manning,
David Ward, Lixia Zhang, Jun Murai and Fred Baker.
11. Acknowledgments
The authors thank to the funding supports of the CERNET, CNGI-
CERNET2, CNGI Research and Development, China "863" and China "973"
projects.
Li, et al. Expires August 13, 2009 [Page 15]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
12. Appendix A. The IVI gateway configuration example
IVI Configuration Example
#!/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:da8:ffca:2661:cc00::/70,
# IVI4 = 202.38.97.204/30
# configure IPv6 route
route add -A inet6 2001:da8:ffca:2661:cc00::/70 \
gw 2001:da8:aaae::206 dev eth0
# config mapping for source-PF = 2001:da8::/32
# config mapping for destination-PF = 2001:da8::/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
# 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 202.38.97.204 255.255.255.252 10.0.0.1 \
eth0 2001:da8:: 2001:da8::
# IPv6-to-IPv4 mapping
# mroute6 destination-PF destination-PF-pref-len
/root/mroute6 2001:da8:ff00:: 40
Figure 8
Li, et al. Expires August 13, 2009 [Page 16]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
13. Appendix B. The traceroute results
ivitraceroute
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 202.38.17.186 1 ms 1 ms 1 ms
202.38 AS4538
6 202.38.17.186 1 ms 1 ms 1 ms
202.38 AS4538
7 202.38.17.186 2 ms 2 ms 2 ms
202.38 AS4538
8 202.38.17.186 2 ms 2 ms 2 ms
202.38 AS4538
9 202.38.17.186 4 ms 4 ms 3 ms
202.38 AS4538
10 202.38.108.2 2 ms 3 ms 3 ms
Figure 9
Note that the non-IVI IPv6 addresses are mapped to 202.38.17.186,
which is defined in this document (the first two sections are the
IPv4 prefix of /16 of the IVI gateway interface and the last two
sections are the autonomous system number 4538).
Li, et al. Expires August 13, 2009 [Page 17]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
ivitraceroute6
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::
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 10
Li, et al. Expires August 13, 2009 [Page 18]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
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::).
14. References
14.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2008] Rekhter, Y. and T. Li, "Implications of Various Address
Allocation Policies for Internet Routing", BCP 7,
RFC 2008, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
Li, et al. Expires August 13, 2009 [Page 19]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source
Discovery Protocol (MSDP) Deployment Scenarios", BCP 121,
RFC 4611, August 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
14.2. Informative References
[APNIC] Ito, K., "Large IPv4 address space Usage trial for Future
IPv6 Deployment", http://www.apnic.net/meetings/25/
program/policy/ito-large-ipv4-trial.pdf .
[CERNET] "CERNET Homepage:
http://www.edu.cn/english_1369/index.shtml".
[CNGI-CERNET2]
"CNGI-CERNET2 Homepage:
http://www.cernet2.edu.cn/index_en.htm".
[COUNT] "IPv4 address count down: http://penrose.uk6x.com/".
[DNS] "Source Code of the IVI DNS
http://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/".
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. van Beijnum, "NAT64/
DNS64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-bagnulo-behave-nat64-00 (work in progress),
Li, et al. Expires August 13, 2009 [Page 20]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
June 2008.
[I-D.v6ops-nat64-pb-statement-req]
Bagnulo, M., Baker, F., and I. van Beijnum, "IPv4/IPv6
Coexistence and Transition: Requirements for solutions",
draft-ietf-v6ops-nat64-pb-statement-req-00 (work in
progress), May 2008.
[IVI4] "Test homepage for the IVI4(i): http://202.38.114.1/".
[IVI6] "Test homepage for the IVI6(i):
http://[2001:250:ffca:2672:0100::0]/".
[JJI07] Joseph, D., Chuang, J., and I. Stocia, "Modeling the
Adoption of new Network Architectures", EECS Department,
University of California, Berkeley Tech. Rep. UCB/
EECS-2007-41, April 2007.
[JSG2008] "A Report of Japaness Study Group on Internet's Smooth
Transition to IPv6:
http://www.soumu.go.jp/joho_tsusin/eng/pdf/080617_1.pdf",
June 2008.
[LINUX] "Source Code of the IVI implementation for Linux:
http://linux.ivi2.org/impl/".
[MVB98] Fiuczynski, M., Lam, V., and B. Bershad , "The design and
implementation of an ipv6/ipv4 network address and
protocol translator", Proceedings of the USENIX Annual
Technical Conference (NO 98), June 1998.
[RFC1744] Huston, G., "Observations on the Management of the
Internet Address Space", RFC 1744, December 1994.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
Relay Translator", RFC 3142, June 2001.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Li, et al. Expires August 13, 2009 [Page 21]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
Historic Status", RFC 4966, July 2007.
Authors' Addresses
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 62785983
Email: xing@cernet.edu.cn
Maoke Chen
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 62785983
Email: mk@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 62785983
Email: congxiao@cernet.edu.cn
Hong Zhang
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 62785983
Email: neilzh@gmail.com
Li, et al. Expires August 13, 2009 [Page 22]
Internet-Draft Prefix-specific Address Mapping (IVI) February 2009
Jianping Wu
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 62785983
Email: jianping@cernet.edu.cn
Li, et al. Expires August 13, 2009 [Page 23]
