summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6219.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6219.txt')
-rw-r--r--doc/rfc/rfc6219.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc6219.txt b/doc/rfc/rfc6219.txt
new file mode 100644
index 0000000..0dd657e
--- /dev/null
+++ b/doc/rfc/rfc6219.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+ This document presents the China Education and Research Network
+ (CERNET)'s IVI translation design and deployment for the IPv4/IPv6
+ coexistence and transition.
+
+ 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.
+
+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.
+
+ 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.
+
+
+
+
+Li, et al. Informational [Page 1]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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. 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.
+
+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
+
+
+
+Li, et al. Informational [Page 2]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+1. Introduction
+
+ 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.
+
+ 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].
+
+1.1. Analysis of IPv4-IPv6 Translation Mechanisms
+
+ 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].
+
+ In order to solve the technical difficulties in NAT-PT, the issues
+ and the possible workarounds are:
+
+
+
+
+
+Li, et al. Informational [Page 3]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ 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.
+
+ 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.
+
+ 3. The states maintained in the translator cause scalability,
+ multihoming, and load-sharing problems. Hence, a stateless
+ translation scheme is preferred.
+
+ 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.
+
+ 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.
+
+ 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.
+
+1.2. CERNET Translation Requirements
+
+ 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]
+
+
+
+Li, et al. Informational [Page 4]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ [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.
+
+ The requirements of the IVI mechanism are:
+
+ 1. It should support both IPv6-initiated and IPv4-initiated
+ communications for the IPv6 clients/servers in "an IPv6 network".
+
+ 2. It should follow current IPv4 and IPv6 routing practice without
+ increasing the global routing table size in both address
+ families.
+
+ 3. It should be able to be deployed incrementally.
+
+ 4. It should be able to use IPv4 addresses effectively due to the
+ IPv4 address depletion problem.
+
+ 5. It should be stateless to achieve scalability.
+
+ 6. The DNS function should be decoupled from the translator.
+
+ The specific IVI design presented in this document can satisfy the
+ above requirements, with the following notes:
+
+ 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.
+
+ 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.
+
+ 3. An ALG is still required for any applications that embed
+ address(es) in the payload.
+
+ 4. Some issues with end-to-end transparency, address referrals, and
+ incompatible semantics between protocol versions still remain, as
+ discussed above.
+
+ 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].
+
+
+
+
+Li, et al. Informational [Page 5]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+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 the IVI mapping mechanism and 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), 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].
+
+ 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].
+
+ IVI translator: The mapping and translation gateway between IPv4 and
+ IPv6 based on the IVI mechanism.
+
+ IVI DNS: Providing the IVI Domain Name System (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
+ 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.
+
+
+
+
+
+
+Li, et al. Informational [Page 6]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ 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.
+
+ ------ ----- ------
+ / 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"
+
+ 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.
+
+ 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.
+
+ +-+-+-+-+-+-+
+ | IVIG4 |
+ +-+-+-+-+-+-+
+ ||
+ \ /
+ \/
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | PREFIX | IPv4 addr | SUFFIX |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ Figure 2: Representing the IPv4 Addresses in IPv6
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 7]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ 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.
+
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | PREFIX | |IVI4| | SUFFIX |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ ||
+ \ /
+ \/
+ -+-+-+
+ |IVI4|
+ -+-+-+
+
+ Figure 3: Representing the IPv6 Addresses in IPv4
+
+3.1. Address Format
+
+ The IVI address format is defined based on an individual ISP's IPv6
+ prefix, as shown in the following figure
+
+ | 0 |32 |40 |72 127|
+ ------------------------------------------------------------------
+ | |ff | | |
+ ------------------------------------------------------------------
+ |<- PREFIX ->|<- IPv4 address ->| <- SUFFIX -> |
+
+ Figure 4: IVI Address Mapping
+
+ 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.
+
+ The IETF standard for the address format is defined in [RFC6052].
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 8]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+3.2. Routing and Forwarding
+
+ Based on the IVI address mapping rule, routing is straightforward, as
+ shown in the following figure
+
+ /-----\ /-----\
+ ( 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
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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].
+
+ Since the IVI translation is stateless, it can support multihoming
+ when the same prefix is used for multiple translators.
+
+
+
+Li, et al. Informational [Page 9]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ Since the IVI translation can be implemented independently in each
+ ISP's network, it can be incrementally deployed in the global
+ Internet.
+
+3.3. Network-Layer Header Translation
+
+ 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 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
+
+ -------------------------------------------------------------
+ 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
+
+
+
+Li, et al. Informational [Page 10]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ The IETF standard for IP/ICMP translation is defined in [RFC6145],
+ which contains updated technical specifications.
+
+3.4. Transport-Layer Header Translation
+
+ 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].
+
+ The IETF standard for transport-layer header translation is defined
+ in [RFC6145], which contains updated technical specifications.
+
+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 the
+ fragmentation field in the IPv4 headers are necessary; this is
+ performed in the IVI translator according to SIIT [RFC2765].
+
+ The IETF standard for fragmentation and MTU handling is defined in
+ [RFC6145], which contains updated technical specifications.
+
+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 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.
+
+ The IETF standard for IP/ICMP translation is defined in [RFC6145],
+ which contains updated technical specifications.
+
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 11]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+3.7. Application Layer Gateway
+
+ 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.
+
+ The discussion of the use of ALGs is in [RFC6144].
+
+4. The IVI DNS Configuration
+
+ The DNS [RFC1035] service is important for the IVI mechanism.
+
+4.1. DNS Configuration for the IVI6(i) Addresses
+
+ 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.
+
+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 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].
+
+5. The Advanced IVI Translation Functions
+
+5.1. IVI Multicast
+
+ The IVI mechanism can support IPv4/IPv6 communication of Protocol
+ Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC5771]
+ [RFC3569] [RFC4607].
+
+ There will be 2^24 group addresses for IPv4 SSM. The corresponding
+ IPv6 SSM group addresses can be defined as shown in the following
+ figure.
+
+
+
+
+
+Li, et al. Informational [Page 12]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ -------------------------------------------------------
+ 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 - Sparse Mode
+ (PIM-SM).
+
+ 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.
+
+6. IVI Host Operation
+
+6.1. IVI Address Assignment
+
+ 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.
+
+ 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 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.
+
+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 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.
+
+
+
+
+
+
+Li, et al. Informational [Page 13]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+7. The IVI Implementation
+
+7.1. Linux Implementation
+
+ 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.
+
+ The IVI DNS source code for the IVIG6(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 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.
+
+ Two traceroute results are presented in Appendix B to show the
+ address mapping of the IVI mechanism.
+
+ IVI6 manual configuration and 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 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, 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.
+
+ 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 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
+
+
+
+
+
+Li, et al. Informational [Page 14]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ DNSSEC, or in the host, if the host both translates the DNS entry
+ and again verifies DNSSEC validity. The DNSSEC discussion is in
+ [RFC6147].
+
+ o 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.
+
+ Except for the issues discussed above, we have not found special
+ security problems introduced by the IVI translation in our
+ experiments.
+
+9. 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, Wentao Shang, Weifeng Jiang, and Bizheng Fu.
+
+ The authors would like to acknowledge the following contributors, who
+ provided helpful inputs concerning the IVI concept: Bill Manning,
+ David Ward, Elwyn Davies, Lixia Zhang, Jun Murai, Fred Baker, Jari
+ Arkko, Ralph Droms, Tony Hain, and Kevin Yin.
+
+10. Acknowledgments
+
+ The authors thank the following for funding support: the CERNET,
+ CNGI-CERNET2, CNGI Research and Development, and the China "863" and
+ China "973" projects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 15]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+Appendix A. The IVI Translator 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:db8:ffc0:2:0::/64,
+ # IVI4 = 192.0.2.0/24
+
+ # configure IPv6 route
+ route add -A inet6 2001:db8:ffc0:2:0::/64 \
+ gw 2001:da8:aaae::206 dev eth0
+
+ # config mapping for source-PF = 2001:db8::/32
+ # config mapping for destination-PF = 2001:db8::/32
+
+ # for each mapping, a unique pseudo-address (10.0.0.x/8)
+ # should be configured.
+ # ip addr add 10.0.0.1/8 dev eth0
+
+ # 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::
+
+ # IPv6-to-IPv4 mapping
+ # mroute6 destination-PF destination-PF-pref-len
+ /root/mroute6 2001:db8:ff00:: 40
+
+ Figure 9: IVI Configuration Example
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 16]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+Appendix B. The traceroute Results
+
+ ivitraceroute 202.38.108.2
+
+ 1 202.112.0.65 6 ms 2 ms 1 ms
+ 2 202.112.53.73 4 ms 6 ms 12 ms
+ 3 202.112.53.178 1 ms 1 ms 1 ms
+ 4 202.112.61.242 1 ms 1 ms 1 ms
+ 5 192.0.2.100 1 ms 1 ms 1 ms
+ 6 192.0.2.102 1 ms 1 ms 1 ms
+ 7 192.0.2.103 2 ms 2 ms 2 ms
+ 8 192.0.2.104 2 ms 2 ms 2 ms
+ 9 192.0.2.105 4 ms 4 ms 3 ms
+ 10 202.38.108.2 2 ms 3 ms 3 ms
+
+ Figure 10: ivitraceroute Results
+
+ Note that the non-IVIG6 addresses are mapped to IPv4 document address
+ 192.0.2.0/24.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 17]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ 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: ivitraceroute6 Results
+
+ 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::).
+
+
+
+Li, et al. Informational [Page 18]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+11. References
+
+11.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.
+
+ [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.
+
+ [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.
+
+ [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
+ (CIDR): The Internet Address Assignment and Aggregation
+ Plan", BCP 122, RFC 4632, August 2006.
+
+
+
+Li, et al. Informational [Page 19]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
+ Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
+ March 2008.
+
+ [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
+ IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
+ March 2010.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ October 2010.
+
+ [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+ IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+ [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+ Algorithm", RFC 6145, April 2011.
+
+ [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.
+
+ [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.
+
+11.2. Informative References
+
+ [BEHAVE] "The IETF Behave Working Group Charter:
+ http://datatracker.ietf.org/wg/behave/charter/".
+
+ [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 countdown: http://penrose.uk6x.com/".
+
+ [DNS] "Source Code of the 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/".
+
+
+
+
+
+Li, et al. Informational [Page 20]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+ [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.
+
+ [RFC3484] Draves, R., "Default Address Selection for Internet
+ Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+ [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific
+ Multicast (SSM)", RFC 3569, July 2003.
+
+ [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
+ Address Translator - Protocol Translator (NAT-PT) to
+ Historic Status", RFC 4966, July 2007.
+
+ [TEST4] "Test homepage for the IVI4(i): http://test4.ivi2.org".
+
+ [TEST6] "Test homepage for the IVI6(i): http://test6.ivi2.org",
+ Available using IPv6 only.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li, et al. Informational [Page 21]
+
+RFC 6219 CERNET IVI Translation Design May 2011
+
+
+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
+
+
+ Congxiao Bao
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ CN
+ Phone: +86 10-62785983
+ EMail: 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
+
+
+ Hong Zhang
+ CERNET Center/Tsinghua University
+ Room 225, Main Building, Tsinghua University
+ Beijing 100084
+ CN
+ Phone: +86 10-62785983
+ EMail: 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
+
+
+
+
+
+
+Li, et al. Informational [Page 22]
+