Network Working Group X. Li Internet-Draft C. Bao Intended status: Informational M. Chen Expires: December 15, 2009 H. Zhang J. Wu CERNET Center/Tsinghua University June 13, 2009 The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition draft-xli-behave-ivi-02 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 December 15, 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Li, et al. Expires December 15, 2009 [Page 1] Internet-Draft CERNET IVI Translation Design June 2009 Abstract This document presents the CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IV stands for 4 and VI stands for 6, so IVI stands for the IPv4/IPv6 translation. The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network connected to the IPv4 Internet" scenario. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in ISP's 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 translators, which can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. This document is a comprehensive report on the CERNET IVI design and its deployment in large scale public networks. Li, et al. Expires December 15, 2009 [Page 2] Internet-Draft CERNET IVI Translation Design June 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 3. The IVI Translation Algorithm . . . . . . . . . . . . . . . . 6 3.1. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 10 3.6. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Application Layer Gateway . . . . . . . . . . . . . . . . 10 4. The IVI DNS Configuration . . . . . . . . . . . . . . . . . . 10 4.1. DNS Configuration for the IVI6(i) Addresses . . . . . . . 11 4.2. DNS Service for the IVIG6(i) Addresses . . . . . . . . . . 11 5. The Advanced IVI translation functions . . . . . . . . . . . . 11 5.1. IVI Multicast . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Double IVI . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Using RFC1918 Address Blocks . . . . . . . . . . . . . . . 12 5.4. IPv4 Address Temporal Multiplexing . . . . . . . . . . . . 12 5.5. IPv4 Address Transport-layer Port Multiplexing . . . . . . 12 6. IVI Host Operation . . . . . . . . . . . . . . . . . . . . . . 13 6.1. IVI Address Assignment . . . . . . . . . . . . . . . . . . 13 6.2. IPv6 Source Address Selection . . . . . . . . . . . . . . 13 7. The IVI Implementation . . . . . . . . . . . . . . . . . . . . 13 7.1. Linux Implementation . . . . . . . . . . . . . . . . . . . 13 7.2. Testing Environment . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 12. Appendix A. The IVI translator configuration example . . . . . 15 13. Appendix B. The traceroute results . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Li, et al. Expires December 15, 2009 [Page 3] Internet-Draft CERNET IVI Translation Design June 2009 1. Introduction This document presents the CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IV stands for 4 and VI stands for 6, so IVI stands for the IPv4/IPv6 translation. The experiences for the IPv6 deployment in the past 10 years strongly indicate that for a successful transition, the communication between IPv4 and IPv6 address families should be supported [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 single-stack hosts can only communicate with the hosts in the same address family. 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]. Since IPv4 and IPv6 are different protocols with different addressing structure, the translation mechanism is 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) [RFC2765], 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, the 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 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 [RFC4966]. CERNET stands for China Education and Research Network and it has two backbones using different address families. The CERNET is IPv4-only and CERNET2 is IPv6-only [CERNET] [CNGI-CERNET2]. In order to make CERNET2 communicate with the IPv4 Internet, we designed IVI mechanism and installed IVI translators between CERNET and CERNET2. It is clear that IVI fits in the "an IPv6 network connected to the IPv4 Internet" scenario in the IETF behave Working Group definition [BEHAVE]. Li, et al. Expires December 15, 2009 [Page 4] Internet-Draft CERNET IVI Translation Design June 2009 The requirements of the IVI mechanisms are: 1. It should be stateless for the scalability. 2. It should support both IPv6 initiated and IPv4 initiated communications for the IPv6 servers in "an IPv6 network". 3. It should follow the current IPv4 and IPv6 routing practice without increasing the global routing table size in both address families. 4. It should be able to be deployed incrementally. 5. It should be able to use IPv4 addresses effectively due to the IPv4 address depletion problem. The IVI mechanism presented in this document can satisfy the above requirements. 2. Terms and Abbreviations The following terms and abbreviations are used in this document: ISP(i): A specific Internet service provider "i". IVIG4: The global IPv4 address space. IPS4(i): A subset of IVIG4 allocated to ISP(i). IVI4(i): A subset of IPS4(i), the addresses in this set will be mapped to IPv6 via IVI mapping mechanism and physically used by IPv6 hosts of ISP(i). IPG6: The global IPv6 address space. IPS6(i): A subset of IPG6 allocated to ISP(i). IVIG6(i): A subset of IPS6(i), an image of IVIG4 in IPv6 address family via IVI mapping mechanism. IVI6(i): A subset of IVIG6(i) and an image of IVI4(i) in IPv6 address family via IVI mapping mechanism. IVI translator: The mapping and translation gateway between IPv4 and IPv6 based on IVI mechanism. Li, et al. Expires December 15, 2009 [Page 5] Internet-Draft CERNET IVI Translation Design June 2009 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]. 3. The IVI Translation Algorithm The IVI is a prefix-specific and stateless address mapping scheme which can be carried out by individual ISPs. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in ISP's 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 translators, which can either be IPv6 initiated or IPv4 initiated. IVI mapping and translation mechanism is implemented in an IVI translator which connects between "an IPv6 network" to the IPv4 Internet via ISP's IPv4 network as shown in the following figure. ------ ----- ------ / The \ ----- / An \ / The \ | IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 | \Internet/ ----- \Network/ \Internet/ ------ ----- ------ Figure 1: An IPv6 network to IPv4 Internet In order to perform the translation function between the IPv4 and IPv6, the translator needs to represent the IPv4 addresses in IPv6 and the IPv6 addresses in IPv4. To represent the IPv4 addresses in IPv6, a unique, prefix-specific and stateless mapping scheme is defined between IPv4 addresses and subsets of IPv6 addresses, so each provider-independent IPv6 address block (usually a /32) will have a small portion of IPv6 addresses (defined by PREFIX), which is the image of the totality of the global IPv4 addresses, as shown in the following figure. The SUFFUX are all zeros. Li, et al. Expires December 15, 2009 [Page 6] Internet-Draft CERNET IVI Translation Design June 2009 +-+-+-+-+-+-+ | IVIG4 | +-+-+-+-+-+-+ || \ / \/ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX | IPv4 addr | SUFFIX | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2: Represent the IPv4 addresses in IPv6 To represent the IPv6 addresses in IPv4, 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, as shown in the following figure. The SUFFIX can either be all zeros or for the future extensions. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PREFIX | |IVI4| | SUFFIX | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ || \ / \/ -+-+-+ |IVI4| -+-+-+ Figure 3: Represent the IPv6 addresses in IPv4 3.1. Address Mapping The IVI address mapping is defined based on individual ISP's prefix as shown in the following figure. | 0 |32 |40 |72 127| ------------------------------------------------------------------ | |FF | | | ------------------------------------------------------------------ |<- PREFIX ->|<- IPv4 address ->| <- SUFFIX -> | Figure 4: IVI Address Mapping Li, et al. Expires December 15, 2009 [Page 7] Internet-Draft CERNET IVI Translation Design June 2009 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 (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. 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 trans. |------------|R2|---(IPv6 ) (network) ---- 192.168.1.1-------------2001:DB8::1 ---- (network) \-----/ \-----/ Figure 5: IVI Routing where 1. Router R1 has IPv4 route of IVI4(i)/k (k is the prefix length of IVI4(i)) with next-hop equals to 192.168.1.1 and this route is distributed to the Internet with proper aggregation. 2. Router R2 has IPv6 route of IVIG6(i)/40 with next-hop equals to 2001:DB8::1 and this route is distributed to the IPv6 Internet with proper aggregation. 3. The IVI translator has IPv6 route of IVI6(i)/(40+k) with next hop equals to 2001:DB8::2. The IVI translator 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 translator 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, they will no affect the global IPv4 and IPv6 routing tables [RFC4632]. Since IVI translator is stateless, it can support multi-homing when same prefix is used. Since IVI can be implemented independently in each ISP's network, it Li, et al. Expires December 15, 2009 [Page 8] Internet-Draft CERNET IVI Translation Design June 2009 can be incrementally deployed. 3.3. Network-layer Header Translation IPv4 [RFC0791] and IPv6 [RFC2460] are different protocols with different network layer header format, the translation of the IPv4 and IPv6 headers MUST be performed according to SIIT [RFC2765] as shown in the following figures. Note that the source and destination address translation is based on the IVI address mapping algorithm, not the SIIT's definition. ------------------------------------------------------------- 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 6: IPv4 to IPv6 Header translation ------------------------------------------------------------- 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 7: IPv6 to IPv4 Header translation Li, et al. Expires December 15, 2009 [Page 9] Internet-Draft CERNET IVI Translation Design June 2009 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. Note that this is different from SIIT, since special IPv6 addresses (IPv4 mapped IPv6 addresses and IPv4 compatible IPv6 addresses) are used in SIIT and results in checksum neutral property [RFC2765]. 3.5. Fragmentation and MTU Handling 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 fragmentation field in the IPv4 headers are necessary, which is performed in the IVI translator 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 IVIG6(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 translator. 4. The IVI DNS Configuration The DNS [RFC1035] service is important for the IVI mechanism. Li, et al. Expires December 15, 2009 [Page 10] Internet-Draft CERNET IVI Translation Design June 2009 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 translator. 4.2. DNS Service for the IVIG6(i) Addresses 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 is in dual stack environment. When the IVI6(i) host queries an 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 an AAAA record to the IVI6(i) host. 5. The Advanced IVI translation functions 5.1. IVI Multicast The IVI mechanism can support IPv4/IPv6 communication of the protocol-independent specific-source sparse-mode multicast (PIM SSM) [RFC3171] [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. ------------------------------------------------------- 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 The source address in IPv6 MUST be IVI6(i) in order to perform reverse path forwarding (RPF) as required by PIM-SM. 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. Li, et al. Expires December 15, 2009 [Page 11] Internet-Draft CERNET IVI Translation Design June 2009 5.2. Double IVI The IVI mechanism can support the double IVI service, i.e. a stub IPv4 network can be connected to an IVI translator to reach the IVI6 network and via another IVI translator to reach the IPv4 Internet [RFC4925] A more interesting scenario is to integrate the functions of the first IVI translator into the end system. In this case, the application software is IPv4 based and there is no need to have ALG support in the IVI translator when it is communicating with IPv4 hosts. 5.3. Using RFC1918 Address Blocks The private IPv4 address blocks [RFC1918] can be used as the IVI4. In this case, an IPv4 NAPT can be used to convert the public IPv4 addresses to private IPv4 addresses and an IVI translator then translate the IPv4 packets to IPv6 packets. Note that the resulting IPv6 addresses are not private addresses since they are embedded into globally routable IPv6 prefixes and this recovers the end-to-end connectivity in the IPv6 Internet for the networks using private IPv4 addresses. 5.4. IPv4 Address Temporal Multiplexing Due to the IPv4 address depletion problem, the effective use of the IPv4 address is important for the IVI mechanism. The multiplexing techniques are temporal multiplexing and transport port multiplexing. The IVI6(i) 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. 5.5. IPv4 Address Transport-layer Port Multiplexing To further increase the utilization ratio of the public IPv4 addresses, the port multiplexing can be used [RFC2766] [RFC4966]. This is to say that a single IPv4 address IVI4(i) can be used for multiple IVI6(i) addresses under the condition that these individual IVI6(i)s host can only use a subset of the 65,536 port numbers. For example, if the port multiplexing ratio is 128, each IVI6(i) can only use 512` concurrent port numbers to communicate with IPv4 Internet. The mapping mechanism is to use the SUFFIX in the IVI address mapping mechanism to define the coding method to the perform unique mapping between IVI4(i) and IVI6(i). The specification of the SUFFIX coding method and the corresponding operation scheme will be presented in Li, et al. Expires December 15, 2009 [Page 12] Internet-Draft CERNET IVI Translation Design June 2009 another document. 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 auto-configuration cannot be used. However, the IVI6 can be assigned to the IPv6 end system via manual configuration or stateful auto-configuration via DHCPv6. 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 should 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 from [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 from [DNS]. 7.2. Testing Environment 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 IPv6 addresses (IVI) behind IVI translator 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 mechanism. The IVI6 manual configuration and the DHCPv6 configuration of the IPv6 end system have also been tested with success. Li, et al. Expires December 15, 2009 [Page 13] Internet-Draft CERNET IVI Translation Design June 2009 8. Security Considerations 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. However, the specific security issues for the IVI translator implementation should be studied and addressed during the development of the IVI mechanisms. 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, Yu Zhai and Wentao Shang. 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, Fred Baker, Tony Hain, Kevin Yin and Jari Arkko . 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 December 15, 2009 [Page 14] Internet-Draft CERNET IVI Translation Design June 2009 12. Appendix A. The IVI translator 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 9 Li, et al. Expires December 15, 2009 [Page 15] Internet-Draft CERNET IVI Translation Design June 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 10 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 translator interface and the last two sections are the autonomous system number 4538). Li, et al. Expires December 15, 2009 [Page 16] Internet-Draft CERNET IVI Translation Design June 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 11 Li, et al. Expires December 15, 2009 [Page 17] Internet-Draft CERNET IVI Translation Design June 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 December 15, 2009 [Page 18] Internet-Draft CERNET IVI Translation Design June 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 . [BEHAVE] "The IETF Behave Working Group Charter: http://www.ietf.org/html.charters/behave-charter.html/". [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/ Li, et al. Expires December 15, 2009 [Page 19] Internet-Draft CERNET IVI Translation Design June 2009 DNS64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-bagnulo-behave-nat64-00 (work in progress), 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. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [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 Li, et al. Expires December 15, 2009 [Page 20] Internet-Draft CERNET IVI Translation Design June 2009 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 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 Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 62785983 Email: congxiao@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 Li, et al. Expires December 15, 2009 [Page 21] Internet-Draft CERNET IVI Translation Design June 2009 Hong Zhang CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 CN Phone: +86 62785983 Email: neilzh@gmail.com 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 December 15, 2009 [Page 22]