Network Working Group Christian Vogt Internet-Draft Ericsson Expires: April 29, 2010 Alain Durand Comcast October 26, 2009 Virtual IPv6 Connectivity for IPv4-Only Networks draft-vogt-durand-virtual-ip6-connectivity-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Vogt & Durand Expires April 29, 2010 [Page 1] Internet-Draft Virtual IPv6 Connectivity October 2009 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. Abstract Although the impetus to invest in interworking between IP versions 4 and 6 is initially on the side of early IPv6 adopters, more substantial IPv6 deployment in the future will shift this impetus towards the side of the legacy IPv4 Internet. However, interworking techniques for IPv4-only networks are as yet largely unexplored. This document proposes Virtual IPv6 Connectivity, a technique for IPv4-only networks to communicate with the IPv6 Internet. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conceptual Overview . . . . . . . . . . . . . . . . . . . . . 4 3. Virtual IP Addresses . . . . . . . . . . . . . . . . . . . . . 6 4. Discovery of Virtual IP Addresses . . . . . . . . . . . . . . 7 5. IP Protocol Translation . . . . . . . . . . . . . . . . . . . 13 6. Multi-Homing Support . . . . . . . . . . . . . . . . . . . . . 18 7. Side-Effects . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Pending Document Changes . . . . . . . . . . . . . . 22 Appendix B. Log of Document Changes . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Vogt & Durand Expires April 29, 2010 [Page 2] Internet-Draft Virtual IPv6 Connectivity October 2009 1. Introduction The deployment of IP version 6 is challenging. Since it requires changes to applications, host stacks, and networks end-to-end, IPv6 deployment involves multiple stakeholders. These stakeholders are in general independent and not coordinated, so a simultaneously transition to IPv6 by all stakeholders is practically impossible. It is therefore necessary to enable the stakeholders to deploy IPv6 independently of each other. This requires interworking between those stakeholders who have already adopted IPv6, and those stakeholders who have not yet. There are two basic approaches to enable interworking between IP versions: o Make IPv6 backwards compatible with IPv4 o Make IPv4 forward compatible with IPv6 Which of the approaches is feasible depends on where the impetus on interworking is -- on the side of early IPv6 adopters, or on the side of the legacy IPv4 Internet. This impetus will shift over time. Initially, the impetus for interworking will naturally be high on the side of early IPv6 adopters. Services and peers will at that point almost exclusively be IPv4-only, so IPv6 adopters will have to make sure they can communicate via IPv4. For the same reason, initial incentives to invest in interworking will be very low on the side of the legacy IPv4 Internet: Why would the legacy IPv4 Internet want to communicate via IPv6 if everything they need is available also via IPv4? However, as IPv6 deployment progresses, more and more services and peers will become IPv6-capable. The interworking impetus on the side of IPv6 adopters will therefore shrink. At some point, a critical mass of IPv6 deployment will have been reached to make it feasible for services and peers to be IPv6-only. And as there are more and more IPv6-only services and peers, the impetus for interworking will grow on the side of the legacy IPv4 Internet, so that those IPv6-only services and peers can be reached. Consequently, interworking between IP versions will initially be realized foremost through backwards compatibility of IPv6 with IPv4, but over time increasinly also through forward compatibilility of IPv4 with IPv6. Due to the immediate need for IPv6 backwards compatibility, the Internet Engineering Task Force has made the design of suitable techniques a task of high priority. However, techniques for IPv4 forward compatibility are as yet largely unexplored. Vogt & Durand Expires April 29, 2010 [Page 3] Internet-Draft Virtual IPv6 Connectivity October 2009 This document proposes Virtual IPv6 Connectivity, a technique to make IPv4 forward compatible with IPv6. Virtual IPv6 Connectivity uses IP protocol translators on the border of IPv4-only networks to enable local hosts to communicate with IPv6-only peers on the Internet. It makes IPv4-only hosts reachable by peers on the Internet via "virtual IPv6 addresses", and it makes IPv6-only peers reachable by IPv4-only hosts via "virtual IPv4 addresses". A virtual IPv6 address is statically mapped to each IPv4 address, and made retrievable via the DNS or DNSSEC. A virtual IPv4 address is mapped to a peer's IPv6 address dynamically and on demand, and made retrievable via DNS proxies or DNSSEC proxies. The IP protocol translators can alternatively be operated by IPv4-only networks directly, or by providers on behalf of IPv4-only networks. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Conceptual Overview To enable hosts in an IPv4-only network to communicate with remote IPv6 peers, Virtual IPv6 Connectivity employs four components: o Virtual IPv4 and IPv6 addresses to represent, respectively, the IPv6 addresses of remote peers to local IPv4-only hosts, and the IPv4 addresses of local hosts to remote IPv6 peers. o IP protocol translators, placed on border links of the IPv4-only network, to translate packets exchanged with remote IPv6 peers. o Support in authoritative DNS servers for returning virtual IPv6 addresses in place of the IPv4 addresses of local IPv4-only hosts when responding to queries from remote IPv6-only peers. o Support in recursive DNS servers for returning virtual IPv4 addresses in place of the IPv6 addresses of remote IPv6-only peers when responding to queries from local IPv4-only hosts. Figure 1 depicts an IPv4-only network that uses Virtual IPv6 Connectivity. The network has an IP protocol translator, denoted "xlate" in the figure, on its border link to the IPv6 Internet. The network also has sets of virtual IPv6 and IPv4 addresses, which, in this example, are taken from the IPv6 address prefix 2001:DB8::/96 and from the IPv4 address prefix 10.0.0.0/8, respectively. The virtual IPv6 addresses represent the regular IPv4 addresses of the IPv4-only network to remote IPv6-only peers. The virtual IPv4 addresses represent the regular IPv6 addresses of remote IPv6-only Vogt & Durand Expires April 29, 2010 [Page 4] Internet-Draft Virtual IPv6 Connectivity October 2009 peers to hosts in the IPv4-only network. Furthermore, the IPv4-only network has authoritative and recursive DNS servers that can return, respectively, virtual IPv4 addresses in place of local IPv4 addresses, and virtual IPv4 addresses in place of remote IPv6 addresses. virtual IPv6 addresses recursive/authoritative 2001:DB8::/96 DNS servers | ( ~~~|~~~~~~~|~~~ | ( ( ['] ['] ) ### ### | ( ( ) ## ## / ( ( v4-only network ) ======== xlate ======== ( v6 Internet ( ) / ## ## ( ( ) | ### ### ( ~~~~~~~~~~~~~~~ | ( | ( virtual IPv4 addresses 10.0.0.0/8 Figure 1: Conceptual overview of Virtual IPv6 Connectivity Packets exchanged between an IPv4 host and an IPv6 peer are always destined to a virtual IP address, and sourced from a regular IP address, when initially dispatched by the sender. Virtual IP addresses route to an IP protocol translator, which performs three tasks for each received packet exchanged between an IPv4 host and an IPv6 peer: o It maps the IP source and destination addresses in a packet, replacing the virtual IP destination address with the represented regular IP address, and replacing the regular IP source address with the representing virtual IP address. o It uses the Stateless IP/ICMP Translation algorithm [RFC2765] to translate the IP header of the packet into an IP header from the respective other IP version. The new IP header uses the IP source and destination addresses determined in the foregoing mapping. o It forwards the packet towards the new IP destination address. Translated packets are consequently always destined to a regular IP address and sourced from a virtual IP address. The pair of a virtual IP address and the represented regular IP address is called a "mapping". Mappings are used in IP protocol Vogt & Durand Expires April 29, 2010 [Page 5] Internet-Draft Virtual IPv6 Connectivity October 2009 translators and DNS servers as a basis for translating packets between IP versions, and for provisioning virtual IP addresses in the DNS. Mappings between IPv4 addresses and virtual IPv6 addresses are static. Each IPv4 address is mapped to a separate virtual IPv6 address by appending it to a 96-bit virtual IPv6 address prefix. This enables stateless, algorithmic mapping in IP protocol translators and authoritative DNS servers. On the other hand, mappings between IPv6 addresses and virtual IPv4 addresses are dynamic and on-demand to enable reuse of virtual IPv4 addresses. This is inevitable because any set of virtual IPv4 addresses is smaller than the global set of regular IPv6 addresses for which mappings are potentially needed. As a consequence, mappings between IPv6 addresses and virtual IPv4 addresses must be statefully maintained by IP protocol translators and recursive DNS servers per communication session. Mapping creation is triggered by a recursive DNS server when receiving a query for an IPv6-only peer's DNS name from an IPv4-only host. The mappings expire when no longer used by a communication session. 3. Virtual IP Addresses For the local hosts in an IPv4-only network to communicate with remote IPv6 correspondent hosts, local hosts and remote correspondent hosts must be able to reach their respective peer with an IP version they support: The local hosts must be able to reach the remote correspondent hosts via an IPv4 address, and the remote correspondent hosts must be able to reach the local hosts via an IPv6 address. Virtual IPv6 Connectivity achieves this reachability across IP versions by means of virtual IPv4 and IPv6 addresses, which respectively map onto the regular IPv6 addresses of remote correspondent hosts and the regular IPv4 addresses of local hosts. Virtual IPv6 addresses represent local hosts in an IPv4-only network to remote IPv6 correspondent hosts. They are ordinary, global IPv6 addresses, which the IPv4-only network obtains either from its Internet service provider or from an Internet registry. Virtual IPv6 addresses are announced externally in the global routing system, but are not used internally within the IPv4-only network. They map one- to-one onto the regular IPv4 addresses in the IPv4-only network, i.e., there is one unique virtual IPv6 address for each regular IPv4 address. There are no restrictions as to how to realize this one-to- one mapping. A simple, recommended way is to reserve a 96-bit IPv6 address prefix, and to map each regular IPv4 address to the virtual IPv6 address that is defined by attaching the 32 bits of the regular IPv4 address to the 96 bits of the reserved 96-bit IPv6 address prefix. Vogt & Durand Expires April 29, 2010 [Page 6] Internet-Draft Virtual IPv6 Connectivity October 2009 Virtual IPv4 addresses represent remote IPv6 correspondent hosts to local hosts in an IPv4-only network. They are ordinary IPv4 addresses that map onto the regular IPv6 addresses of the remote correspondent hosts. Virtual IPv4 addresses are announced internally in the local routing system of an IPv4-only network, but are not used outside the IPv4-only network. Since virtual IPv4 addresses are used only locally within an IPv4-only network, they can be non-global. This makes them re-usable in different IPv4-only networks with Virtual IPv6 Connectivity. As an example, virtual IPv4 addresses could be taken from the private net-10 or 192.168.0.0/16 address spaces [###RFC1918], or from a new IPv4 address block specifically allocated for use in IPv4-only networks with Virtual IPv6 Connectivity. Different than mappings between regular IPv4 addresses and virtual IPv6 addresses, mappings between regular IPv6 addresses and virtual IPv4 addresses cannot be one-to-one because the set of regular IPv6 addresses that potentially need to be mapped is larger than any pool of virtual IPv4 addresses. Mappings between regular IPv6 addresses and virtual IPv4 addresses may instead change dynamically depending on the set of remote IPv6 correspondent hosts that communicate with an IPv4-only network. Mappings between regular IPv6 addresses and virtual IPv4 addresses are therefore created in an on-demand manner, and they have a lifetime after which they may be replaced. In the example of Figure 1, the IPv4-only network has obtained the 96-bit IPv6 address prefix 2001:DB8::/96 for virtual IPv6 addresses, so any IPv4 address a.b.c.d from the IPv4-only network can be mapped one-to-one to a virtual IPv6 address 2001:DB8::a.b.c.d. The IPv4- only network furthermore uses the private net-10 address space, 10.0.0.0/8, for virtual IPv4 addresses. So for any remote IPv6 correspondent host that communicates with a local host in the IPv4- only network, a virtual IPv4 address is allocated from the 8-bit IPv4 address prefix 10.0.0.0/8, and is temporarily mapped to the remote correspondent host's regular IPv6 address. 4. Discovery of Virtual IP Addresses Communications between between an IPv4-only host and an IPv6-only peer require that the initiator of a new communication obtains a virtual IP address for its peer: An IPv6-only peer intending to reach an IPv4-only host must obtain a virtual IPv6 address for the IPv4- only host; an IPv4-only host intending to reach an IPv6-only peer must obtain a virtual IPv4 address for the IPv6-only peer. To support the discovery of virtual IP addresses, Virtual IPv6 Connectivity makes virtual IPv4 and IPv6 addresses available via the DNS. This section describes the extensions for recursive and Vogt & Durand Expires April 29, 2010 [Page 7] Internet-Draft Virtual IPv6 Connectivity October 2009 authoritative DNS servers in an IPv4-only network that are necessary for this. 4.1. Discovery of Virtual IPv6 Addresses For an IPv6-only peer to obtain via the DNS the virtual IPv6 addresses of a host in an IPv4-only network, the authoritative DNS servers in the IPv4-only network must provide records of type AAAA containing the host's virtual IPv6 addresses. That is, whenever the DNS resolves a host's DNS name into an IPv4 address of that host, the same DNS name must also resolve to the corresponding virtual IPv6 address. The retrieval of virtual IPv6 addresses via DNS then does not differ from the retrieval of regular IPv4 addresses. Furthermore, the virtual IPv6 addresses maintained by an authoritative DNS server for an IPv4-only host should automatically adapt when the host's regular IPv4 addresses change in order to support dynamic DNS updates: Since the mapping between IPv4 addresses and the corresponding virtual IPv6 addresses is static, a change in a host's IPv4 address implies that also a virtual IPv6 address of the host changes. The change of the corresponding type-AAAA record should be pursued by the authoritative DNS server. Hosts cannot be expected to update records of type AAAA because they are generally unaware of their virtual IP addresses. To enable accurate provisioning of virtual IPv6 addresses via the DNS, Virtual IPv6 Connectivity calls for authoritative DNS servers to synthesize type-AAAA records on demand whenever an IPv6 address is being requested by a remote peer. This guarantees that the type-AAAA records in a DNS reply contain exactly those virtual IPv6 addresses that correspond to the IPv4 addresses of the host whoose DNS name is being resolved. IPv6 correspondent authoritative DNS server host in IPv4-only network | | | DNS query: AAAA for host.v4.net? | |-------------------------------------------> | | | | DNS reply: AAAA for host.v4.net | | with 2001:DB8:ABC::a.b.c.d | | <-------------------------------------------| | | Figure 2: Discovery of virtual IPv6 addresses via the DNS Vogt & Durand Expires April 29, 2010 [Page 8] Internet-Draft Virtual IPv6 Connectivity October 2009 Figure 4 shows the resolution of an IPv4-only host's DNS name into a virtual IPv6 address. In this example, the DNS name is "host.v4.net", and it resolves into the regular IPv4 address a.b.c.d. The virtual IPv6 address prefix is 2001:DB8:ABC::/96 in this example, so the host's IPv4 address maps to the virtual IPv6 address 2001:DB8: ABC::a.b.c.d. The message exchange in the figure begins where a remote peer queries an authoritative DNS server in the IPv4-only network for a record of type AAAA associated with DNS name "host.v4.net". The authoritative DNS server replies with a type-AAAA record containing the virtual IPv6 address 2001:DB8:ABC::a.b.c.d. 4.2. Discovery of Virtual IPv4 Addresses For an IPv4-only host to obtain via the DNS the virtual IPv4 addresses of a remote IPv6-only peer, the DNS must provide records of type A containing the peer's virtual IPv4 addresses. However, different than virtual IPv6 addresses, virtual IPv4 addresses generally cannot be provisioned directly by the DNS server that is authoritative for the corresponding regular IP addresses. A DNS server handing out virtual IPv4 addresses must have an administrative relationship with the IPv4-only network to which the virtual IPv4 addresses belong. This relationship generally does not exist for DNS servers authoritative for a remote peer's regular IPv6 addresses. To enable the retrieval of virtual IPv4 addresses via the DNS despite the missing administrative relationship between the authoriative DNS server and the IPv4-only network, Virtual IPv6 Connectivity calls for recursive DNS servers in IPv4-only networks to serve as proxies for the authoritative DNS servers of IPv6-only peers. Thus, when requested by an IPv4-only host to resolve the DNS name of an IPv6- only peer, a recursive DNS server retrieves the peer's regular IPv6 addresses, triggers the creation of a mapping for those regular IPv6 addresses, and returns the corresponding virtual IPv4 addresses on behalf of the peer's authoritative DNS server. Since mappings between virtual IPv4 addresses and regular IPv6 addresses are dynamic, they must be carefully coordinated between IP protocol translators and recursive DNS servers if created during DNS name resolution. Lack of coordination can lead to loss of packets exchanged between IPv4-only hosts and IPv6-only peers due to incorrect translation. To guarantee the coordination of mappings, Virtual IPv6 Connectivity requires all mappings between virtual IPv4 addresses and regular IPv6 addresses to be created by IP protocol translators. Accordingly, recursive DNS servers must request a mapping from an IP protocol translator when needed for a peer's regular IPv6 address. Given such a request, an IP protocol translator first checks if a mapping already exists for the peer's regular IPv6 address. If so, the IP protocol translator returns this Vogt & Durand Expires April 29, 2010 [Page 9] Internet-Draft Virtual IPv6 Connectivity October 2009 mapping to the recursive DNS server. If no mapping exists for the peer's regular IPv6 address, the IP protocol translator creates a new mapping, stores the mapping locally for subsequent translation of packets, and returns a copy of the mapping to the requesting recursive DNS server. The recursive DNS server finally generates a DNS reply and removes the mapping afterwards. IP protocol translators maintain pools of virtual IPv4 addresses that are currently not used in a mapping. They use virtual IPv4 addresses from these pools to create new mappings. The reason for requiring IP protocol translators, rather than recursive DNS servers, to be in control of mappings is to spare the overhead of coordinating mappings that are created based on packets received by an IP protocol translator. These mappings are created for the first packet in communication sessions initiated by a remote IPv6-only peer. Having the IP protocol translator create the mapping in those cases removes the need to coordinate the mapping with a recursive DNS server. Coordination between the IP protocol translator and the recursive DNS server is then only necessary for mappings created during DNS name resolution initiated by IPv4-only hosts. The overall operation of a recursive DNS server in an IPv4-only network more specifically proceeds as follows: o Upon receiving a DNS query from a local IPv4-only host for records of type A associated with a peer's DNS name, the recursive DNS server first attempts to retrieve the records of type A directly from the peer's authoritative DNS server. This is the standard operation of a recursive DNS server. o If the recursive DNS server receives a DNS reply with one or more records of type A, it returns the DNS reply unchanged to the resolving IPv4-only host. The peer in this case is reachable via IPv4, and it is not necessary to allocate a virtual IPv4 address for the peer. o If the recursive DNS server fails to receive a DNS reply with a record of type A, the peer cannot be reached at a regular IPv4 address. The recursive DNS server in this case attempts to retrieve records of type AAAA associated with the peers's DNS name. o If the recursive DNS server receives a DNS reply with one or more records of type AAAA, the peer can be reached via IPv6. The recursive DNS server in this case requests a mapping for each of the regular IPv6 addresses in those records from the IP protocol translator. It then synthesizes a DNS reply with a record of type Vogt & Durand Expires April 29, 2010 [Page 10] Internet-Draft Virtual IPv6 Connectivity October 2009 A for each virtual IPv4 address in a received mapping, and it returns this DNS reply to the resolving IPv4-only host. The recursive DNS server does not store the mappings received from the IP protocol translator. o If the recursive DNS server fails to receive a DNS reply with records of either type A or type AAAA, it returns an error notification to the resolving IPv4-only host. The peer is in this case unreachable from the IPv4-only host. As an optimization to reduce latency, a recursive DNS server may send DNS queries for type-A and type-AAAA records simultaneously to the DNS server authoritative for the peer. With this optimization, if no type-A records can be retrieved, the latency related to retrieving type-AAAA records can be reduced or eliminated. IP protocol translators remove mappings between virtual IPv4 addresses and regular IPv6 addresses that appear to be no longer in use. To keep track of which mappings are in use, IP protocol translators should maintain an expiration timer for each mapping. The expiration timer for a mapping is set at the time the mapping is created. It is reset whenver a mapping for the same regular IPv6 address is requested, and whenever the mapping is used to translate a packet. After a mapping's expiration timer has reached zero, the mapping should be removed, and the virtual IPv4 address from the mapping should be returned to the IP protocol translator's pool of unallocated virtual IPv4 addresses. Vogt & Durand Expires April 29, 2010 [Page 11] Internet-Draft Virtual IPv6 Connectivity October 2009 IPv4-only host recursive DNS DNS server | name server authoritative for | | correspondent host | | | | DNS query: | DNS query: | | A for host.v6.net? | A for host.v6.net? | |--------------------> |-----------------------------> | | | | | | DNS reply: | | | no A for host.v6.net | | | <-----------------------------| | | | | | DNS query: | | | AAAA for host.v6.net? | | |-----------------------------> | | | | | | DNS reply: | | | AAAA for host.v6.net | | | is 2001:DB8:BCD::X:Y:Z | | | <-----------------------------| | | | | +----------------------------------+ | | | create mapping state | | | | 2001:DB8:BCD::X:Y:Z <-> 10.u.v.w | | | +----------------------------------+ | | | | | DNS reply: | | | A for host.v6.net | | | is 10.u.v.w | | | <--------------------| | | | | Figure 3: Discovery of virtual IPv4 addresses via the DNS Figure 3 illustrates the operation of a recursive DNS server in an IPv4-only network with Virtual IPv6 Connectivity. The IPv4-only host on the left of the figure queries a recursive DNS server in the middle for records of type A associated with the DNS name of an IPv6- only peer. The DNS name of the peer is "host.v6.net" in this example, and this is associated with a single record of type AAAA for IPv6 address 2001:DB8:BCD::X:Y:Z. Since only IPv4 addresses are of use for the IPv4-only host, the host naturally does not send a DNS query for records of type AAAA. The recursive DNS server first processes the DNS query unchanged, so it tries to retrieve records of type A from the DNS server that is authoritative for the peer, as represented on the right of Figure 3. This fails because the peer does not have an IPv4 address. In a second attempt, the recursive Vogt & Durand Expires April 29, 2010 [Page 12] Internet-Draft Virtual IPv6 Connectivity October 2009 DNS name server queries for records of type AAAA. This is successful; the recursive DNS server receives a record with IPv6 address 2001:DB8:BCD::X:Y:Z. The recursive DNS server then obtains from an IP protocol translator in the IPv4-only network a mapping between the regular IPv6 address 2001:DB8:BCD::X:Y:Z and a virtual IPv4 address that routes to this IP protocol translator. In the example of Figure 3, this virtual IPv4 address is 10.u.v.w. The recursive DNS server finally returns a DNS reply to the resolving IPv4-only host that contains a record of type A containing the virtual IPv4 address 10.u.v.w. 5. IP Protocol Translation In addition to the mapping between regular IP addresses from one IP version and virtual IP addresses from the respective other IP version, packets exchanged between the local hosts in an IPv4-only network and remote IPv6 correspondent hosts must be converted from IPv4 to IPv6 and vice versa on the border between the IPv4-only network and the IPv6 Internet. For this purpose, IPv4-only networks with Virtual IPv6 Connectivity deploy IP protocol translators on each border link that shall be enabled for communications with remote IPv6 correspondent host. An IP protocol translator is a router with the extra capabilities to map between regular and virtual IP addresses, and to convert packets between IPv4 and IPv6 using the appropriate mapping. Figure 1 illustrates an IPv4-only network with one border link, which is endowed with an IP protocol translator to achieve Virtual IPv6 connectivity for the IPv4-only network. Since in general not all packets traversing a border link need to be translated between IPv4 and IPv6, IP protocol translators must have a means to distinguish packets that require translation from packets that can be forwarded without modification. IP protocol translators perform this differentiation based on the packets' IP destination address: Packets destined to a regular IP address do not require translation, whereas packets destined to a virtual IP address do. This rule is independent of whether packets originate within and leave the IPv4-only network, or whether the packets originate outside and enter the IPv4-only network. For packets that are destined to a regular IP address, an IP protocol translator behaves as an ordinary router. For packets that are destined to a virtual IP address, the IP protocol translator performs three tasks: o It maps the IP source and destination addresses in a packet, replacing the virtual IP destination address with the represented regular IP address, and replacing the regular IP source address with the representing virtual IP address. Vogt & Durand Expires April 29, 2010 [Page 13] Internet-Draft Virtual IPv6 Connectivity October 2009 o It uses the Stateless IP/ICMP Translation Algorithm [SIIT] to translate the IP header of the packet into an IP header from the respective other IP version. The new IP header uses the IP source and destination addresses determined in the foregoing mapping. o It forwards the packet towards the new (regular) IP destination address. ### DESCRIBE WHEN TRANSLATOR CREATES MAPPING? ### To ensure that packets pass through an IP protocol translator if exchanged between a host in an IPv4-only network and a remote IPv6 correspondent host, the routes towards virtual IPv4 and IPv6 addresses must lead to an IP protocol translator. Routes to virtual IPv4 addresses must be available within the IPv4-only network; they lead to the interface of an IP protocol translator that faces the IPv4-only network. Routes to virtual IPv6 addresses must be available in the Internet; they lead to the Internet-facing interface of an IP protocol translator. Thus, when a remote IPv6 correspondent host sends a packet to the virtual IPv6 address of a local host in the IPv4-only network, the packet routes to an IP protocol translator, which translates the packet's virtual IPv6 destination address into the mapped regular IPv4 destination address, and the packet's regular IPv6 source address into a mapped virtual IPv4 source address. Vice versa, when the local host in the IPv4-only network sends a packet to a remote IPv6 correspondent host, an IP protocol translator translates the packet's regular IPv4 source address into the mapped virtual IPv6 source address, and the packet's virtual IPv4 destination address into the mapped regular IPv6 destination address. Both local host and remote correspondent host therefore use only their respective IP version; the peer's regular IP address from the other IP version is transparent to them. There are different means to provision routes to virtual IP addresses. One is through dynamic route announcements by IP protocol translators. IP protocol translators then announce routes towards virtual IPv6 addresses on their interfaces towards the IPv6 Internet, and routes towards virtual IPv4 addresses on their interfaces towards the IPv4-only network. Static configuration is an alternative for part of the routes. Routes to virtual IPv4 addresses can be statically configured in routers of the IPv4-only network. Routes to virtual IPv6 addresses can be statically configured between the IPv4- only network and its provider, if the IP protocol translators are located on the side of the IP-only network. In the latter case, it is the IPv4-only network's provider that dynamically announces a route to virtual IPv6 addresses towards the Internet. Routes to virtual IP addresses may be aggregated with routes to other Vogt & Durand Expires April 29, 2010 [Page 14] Internet-Draft Virtual IPv6 Connectivity October 2009 IP addresses. For example, the route to virtual IPv4 addresses within an IPv4-only network may be a default route. Figure 4 illustrates the the case where routes to virtual IP addresses are dynamically announced, using the IPv4-only network from Figure 1. announces route to virtual IPv6 address prefix 2001:DB8::/96 | ( ~~~~~~~~~~~~~~~ | ( ( ) ### ### | ( ( ) ## ## -----> ( ( v4-only network ) ======== xlate ======== ( v6 Internet ( ) <----- ## ## ( ( ) | ### ### ( ~~~~~~~~~~~~~~~ | ( | ( announces route to virtual IPv4 address prefix 10.0.0.0/8 Figure 4: Route announcement for virtual IP addresses Since the explicit routes towards virtual IP addresses ensure that packets are routed via an IP protocol translator if they require translation between IPv4 and IPv6, IPv4-only networks with Virtual IPv6 Connectivity may deploy IP protocol translators on only some, but not all of their border links. This can reduce the expenses for deployment and operation of Virtual IPv6 Connectivity. Since the communication between a host in an IPv4-only network and a remote IPv6 correspondent host would break if the mapping between either host's regular and virtual IP addresses changed throughout the course of the communication, IP protocol translators must ensure that mappings are stable for the duration of the communications in which they are used. This is trivial for the mappings between regular IPv4 addresses and virtual IPv6 addresses because these mappings are one- to-one and therefore constant. However, as one-to-one mappings are not possible between the large set of regular IPv6 addresses and the necessarily smaller set of virtual IPv4 addresses, IP protocol translators need state to ensure that these mappings remain constant during the communications in which they are used. An IP protocol translator establishes such state in either of two ways, depending on which way a communication is established: Vogt & Durand Expires April 29, 2010 [Page 15] Internet-Draft Virtual IPv6 Connectivity October 2009 o For communications that are initiated by a local host in an IPv4- only network, mapping state is created at the time the local host retrieves the remote IPv6 correspondent host's virtual IPv4 address via the DNS. This ensures that the IP protocol translator can map the virtual IPv4 address in the first packet that the local host sends to the remote correspondent host. Mapping state creation is in this case initiated by a recursive DNS name server from the IPv4-only network. This will be explained further in Section 4. o For communications that are initiated by a remote IPv6 correspondent host, the creation of mapping state is postponed to the time the IP protocol translator receives the first packet that the remote correspondent host sends to the local host in the IPv4- only network. It is then the IP protocol translator which initiates mapping state creation. Postponing the creation of mapping state is possible in this case because the remote correspondent host does not use the virtual IPv4 address for which mapping state is created. The postponement then has the advantage that both the creation of mapping state as well as the allocation of a virtual IPv4 address happens only when there is actually a communication using it. The involvement of both IP protocol translators and recursive DNS name servers in the creation of mapping state and in the allocation of virtual IPv4 addresses calls for coordination between IP protocol translators and recursive DNS name servers: IP protocol translators must have relevant mapping state even if the creation of the state was initiated by a recursive DNS name server; and simultaneous allocation of a given virtual IPv4 address by both an IP protocol translator and a recursive DNS name server must be avoided. This document assumes that sufficient coordination is in place between IP protocol translators and recursive DNS name servers. IP protocol translators and recursive DNS name servers may be co-located to simplify their coordination, or they may coordinate by means of a protocol specified outside of this document. It is recommended that the maintenance of virtual IPv4 addresses is with the IP protocol translator to which they route. This accelerates packet forwarding when the creation of mapping state is inititated by an IP protocol translator, and it hence accounts for the commonly stricter delay constraints on packet forwarding in routers compared to those on DNS lookups. Vogt & Durand Expires April 29, 2010 [Page 16] Internet-Draft Virtual IPv6 Connectivity October 2009 IPv4 host IP protocol IPv6 correspondent | translator host | | | | | from 2001:DB8:BCD::X:Y:Z | | | to 2001:DB8:ABC::a.b.c.d | | | <---------------------------------| | | | | +----------------------------------+ | | | create mapping state | | | | 2001:DB8:BCD::X:Y:Z <-> 10.u.v.w | | | +----------------------------------+ | | | | | from 10.u.v.w | | | to a.b.c.d | | | <----------------| | | | | | from a.b.c.d | from 2001:DB8:ABC::a.b.c.d | | to 10.u.v.w | to 2001:DB8:BCD::X:Y:Z | |----------------> |---------------------------------> | | | | | from 10.u.v.w | from 2001:DB8:BCD::X:Y:Z | | to a.b.c.d | to 2001:DB8:ABC::a.b.c.d | | <----------------| <---------------------------------| | | | Figure 5: Mapping state creation and packet translation for a communication initiated by an IPv6 correspondent host Figure 5 illustrates the mapping state creation and the translation of packets between IPv4 and IPv6 for a communication that is initiated by a remote IPv6 correspondent host. The packets are exchanged between a local host in an IPv4-only network on the left, and the remote IPv6 correspondent host on the right. The IPv4-only network uses Virtual IPv6 Connectivity, so the packets traverse an IP protocol translator. Continuing from previous examples, virtual IPv6 addresses are taken from the IPv6 address prefix 2001::DB8:ABC::/96, and virtual IPv4 addresses are taken from the private net-10 address space, 10.0.0.0/8. The local host's regular IPv4 address, a.b.c.d, maps to the virtual IPv6 address 2001:DB8:ABC::a.b.c.d. This mapping is constant. The remote correspondent host's regular IPv6 address, 2001:DB8:BCD::X:Y:Z, maps to the virtual IPv4 address 10.u.v.w. This mapping is temporary and created in on-demand manner. The dynamic state for the mapping between the regular IPv6 address 2001:DB8:BCD:: X:Y:Z and the virtual IPv4 address 10.u.v.w is created when the first packet in the communication reaches the IP protocol translator. Once the state is created, subsequent packets from the same communication can be translated from IPv6 to IPv4 and vice versa, as shown in the Vogt & Durand Expires April 29, 2010 [Page 17] Internet-Draft Virtual IPv6 Connectivity October 2009 figure. 6. Multi-Homing Support A technique for networks to increase the performance and reliability of their Internet connectivity is to establish multiple border links to either the same or different providers. This technique is called "multi-homing". To combine multi-homing with Virtual IPv6 Connectivity, an IPv4-only network must ensure that packets exchanged between local IPv4 hosts and remote IPv6 correspondent hosts pass through an IP protocol translator that is aware of the mappings for the virtual IP addresses used in the packets. This can be achieved in one of the following two ways: o Shared virtual IP addresses -- A route to a virtual IPv4 or IPv6 address originates at all IP protocol translators, and all IP protocol translators can handle the mapping for all virtual IP addresses. This requires synchronization of mapping state across IP protocol translators. o Unshared virtual IP addresses -- A route to each virtual IPv4 or IPv6 address originates at exactly one IP protocol translator, and only that IP protocol translator can handle the mapping for the virtual IP address. It is then sufficient to maintain mapping state for a given virtual IPv4 address in only one IP protocol translator. Sharing virtual IP addresses across multiple IP protocol translators provides a basis for automated fail-over and dynamic load balancing between border links. Fail-over from a failing IP protocol translator to a backup happens automatically due to the redundancy of routes for a given virtual IP address. Dynamic load balancing can be achieved if the routes to virtual IP addresses are dynamically announced. Virtual IP addresses can then be dynamically divided across available IP protocol translators. On the other hand, shared virtual IP addresses require IP protocol translators to map the complete set of virtual IP addresses in a consistent manner. This implies two costs: First, it involves more mapping state for each IP protocol translator, since mappings must be stored even when unused. Second, it necessitates synchronization between IP protocol translators to ensure mapping consistency. Whereas the mapping consistency for virtual IPv6 addresses can be guaranteed by pre- configuration due to the staticness of these mappings, mappings for virtual IPv4 addresses are dynamic and must hence be synchronized across IP protocol translators. Synchronization of mapping state for virtual IPv4 addresses may be Vogt & Durand Expires April 29, 2010 [Page 18] Internet-Draft Virtual IPv6 Connectivity October 2009 proactive or on-demand. Proactive synchronization ensures that IP protocol translators have a consistent view of all mappings at any time. This requires immediate mapping updates whenever a new mapping is created. On-demand synchronization enables IP protocol translators to retrieve any missing mapping they may need to process a packet. The mappings of virtual IPv4 addresses may then be centrally maintained in a single database that IP protocol translators can query when needed. Unshared virtual IP addresses can be used without synchronization between IP protocol translators. It is instead sufficient to ensure that the virtual IPv4 and IPv6 addresses that are used in the mappings for a particular communication belong to partitions from the same IP protocol translator. The disjoint route announcements of the IP protocol translators then ensure that packets exchanged between IPv4 and IPv6 hosts always route to the IP protocol translator that can map the IP addresses in the packets. A disadvantage of partitioned virtual IP addresses is that active communications cannot be switched to a different IP protocol translator for the purpose of fail-over or load balancing because they are bound to a route via a particular IP protocol translator. Although active communications cannot be switched between IP protocol translators, communications that are newly established should be able to go via any IP protocol translator of an IPv4-only network. The partitioning of virtual IPv4 addresses does not prevent this: Since the mappings for virtual IPv4 addresses are dynamically created, they can be created with a virtual IPv4 address that routes to a preferred IP protocol translator. However, the mappings for virtual IPv6 addresses cannot reflect a current preference for a specific IP protocol translator because those mappings are constant. So to enable the establishment of a new communication via any IP protocol translator, each regular IPv4 address of a host within the IPv4-only network must be mapped to multiple virtual IPv6 addresses, one for each IP protocol translator. The decision of whether to use shared vs. partitioned virtual IP addresses may have an impact on whether a multi-homed IPv4 network can use virtual IPv6 addresses that have been allocated to its provider: If the border links of the multi-homed IPv4 network connect to different providers, virtual IPv6 addresses must be provider- independent in order to be shared across IP protocol translators. This may cause additional load for the global routing system because routes towards the virtual IPv6 addresses could not be announced in aggregated manner. It is therefore recommended that multi-homed IPv4 networks with border links to multiple providers use virtual IPv6 addresses that are provider-allocated, and hence by necessity partitioned virtual IP addresses. Vogt & Durand Expires April 29, 2010 [Page 19] Internet-Draft Virtual IPv6 Connectivity October 2009 7. Side-Effects The translation of IP addresses in the network without explicit coordination with applications and host stacks inevitably leads to side-effects. The following explains the side-effects of Virtual IPv6 Connectivity, and shows why those are unavoidable given the objectives for which Virtual IPv6 Connectivity was designed. The side-effects of Virtual IPv6 Connectivity are three-fold: o It may interfere with applications that expect addresses not to change in packets en route. o It may cause the establishment of new communication sessions to fail due to the unavailability or staleness of a virtual IPv4 address. o It requires the use of a recursive DNS server for name resolution by IPv4-only hosts. Interferences may affect applications that use address referrals inside packet payloads. Since the translation between IPv4 and IPv6 addresses affects only the IP headers in packets, but no address referrals inside packet payloads, addresses referenced in packet payloads may become unreachable when a packet traverses an address translator. Special support, either in the applications themselves or in the address translator, can mitigate the problem. But such special support cannot be guaranteed for every application. Unavailability of virtual IPv4 addresses may cause the establishment of new communication sessions to fail if a large number of IPv6-only hosts communicate with an IPv4-only network. In such a case, the pool of virtual IPv4 addresses may temporarily be exhausted. Staleness of virtual IPv4 addresses can cause session establishment failures if an application uses a virtual IPv4 address a long time after it was mapped to the corresponding regular IPv6 address. The virtual IPv4 address may at that point have been mapped to a different regular IPv6 address, as mappings between regular IPv6 addresses and virtual IPv4 addresses are dynamic. The need for recursive DNS servers in IPv4-only networks precludes direct resolution of DNS names by hosts, and requires configuration of hosts in IPv4-only networks with a recursive DNS server. While this requirement is often negligible due to the widespread use of recursive DNS servers, preventing direct DNS name resolution altogether is typically difficult. All of these side-effects are unavoidable, since they are a Vogt & Durand Expires April 29, 2010 [Page 20] Internet-Draft Virtual IPv6 Connectivity October 2009 consequence of the objectives for which Virtual IPv6 Connectivity was designed, that is, to enable bilateral communications between IPv4- only hosts and IPv6-only peers with upgrades only to IPv4-only networks: o The objective to upgrade only IPv4-only networks requires that addresses are translated, in the network, without explicit coordination with host stacks and applications. This may cause interference with applications that expect addresses not to change in packets en route. o The objective to enable bilateral communications between IPv4-only hosts and IPv6-only peers requires that IPv6-only peers must be represented to IPv4-only hosts via virtual IPv4 addresses. The mappings between regular IPv6 addresses and virtual IPv4 addresses must be dynamic, since no set of IPv4 addresses can be large enough to provide for static virtual IPv4 addresses for all potential IPv6-only peers. This may cause the establishment of new communication sessions to fail due to the unavailability or staleness of a virtual IPv4 address. o The need to translate addresses without explicit coordination with host stacks and applications calls for the use of recursive DNS servers by IPv4-only hosts, in order to handle the translation of DNS messages from regular IPv6 addresses to virtual IPv4 addresses. Even though it would be possible to translate DNS messages without recursive DNS server, doing so would defeat the use of DNS security extensions. 8. Security Considerations No security considerations yet; to be written down. 9. IANA Considerations This document has no actions for IANA. 10. Acknowledgment Many ideas in Virtual IPv6 Connectivity were originally proposed in 2002 by Alain Durand [draft-durand-ngtrans-nat64-nat46]. The authors would like to thank Edward Jankiewicz, Dave Thaler, and Brian Carpenter for their reviews of this document and their valuable comments. Vogt & Durand Expires April 29, 2010 [Page 21] Internet-Draft Virtual IPv6 Connectivity October 2009 This document was generated using the xml2rfc tool. 11. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. Appendix A. Pending Document Changes This section identifies pending document changes, proposed by a reviewer or author, that have not been addressed so far. o Describe the extent to which Virtual IPv6 Connectivity supports DNSSEC, and explain how DNSSEC can be put to use. (Comment from Brian Carpenter.) o Describe how reverse DNS lookups function for virtual IP addresses. (Comment from Brian Carpenter.) o Integrate support for IPv4/IPv4 address translation for communication sessions with IPv4 peers? (Comment from Edward Jankiewicz. Needs working group feedback.) Appendix B. Log of Document Changes The following is a list of technical changes that were made from version 00 to version 01 of the document. Editorial revisions are not explicitly mentioned. Part of the technical and editorial document changes address review comments received from Dave Thaler. o Revised abstract and introduction to emphasize that the impetus to invest in IPv4/IPv6 interworking will shift towards the legacy IPv4 Internet as IPv6 becomes more deployed. o Clarified that virtual IP address prefixes used in figures and examples throughout the document are not mandatory. Which prefixes are used is up to the network operator/administrator deploying Virtual IPv6 Connectivity. o Clarified in which situations an a-priori DNS name resolution is needed to initiate a new communication session. Vogt & Durand Expires April 29, 2010 [Page 22] Internet-Draft Virtual IPv6 Connectivity October 2009 o Elaborated on how routes towards virtual IP addresses can be established. Besides announcement of these routes by IP address translators, the document now also mentiones static configuration, and aggregation of the routes within a default route. o Highlighted the importance of coordination between IP protocol translators and recursive DNS servers. Still need to specify such coordination in more detail. o Explained how dynamic DNS updates work. This required a clarification of how authoritative DNS servers generate type-AAAA records for virtual IPv6 addresses. o Elaborated on the pros and cons of the two multi-homing techniques described in section 6, "Multi-Homing". Section 6 still requires more work. The following is a list of technical changes that were made from version 01 to version 02 of the document. Editorial revisions are not explicitly mentioned. Part of the technical and editorial document changes address review comments received from Edward Jankiewicz. o Revised the conceptual overview. o Swapped the order of sections 4 and 5, "IP Protocol Translation" and "Discovery of Virtual IP Addresses", respectively. The reason for originally having the former section first was that it included information about address mappings that was useful for the latter section. However, the comment that the new order is easier to follow for the reader is a good one. o Revised sections 4 and 5, "IP Protocol Translation" and "Discovery of Virtual IP Addresses", to accommodate the change of order of these sections (see previous bullet). o Clarified that address mappings are maintained by IP protocol translators, not by recursive DNS servers. Recursive DNS servers may only trigger the creation of a new address mapping during DNS name resolution. Elaborated further on the coordination between IP protocol translators and recursive DNS servers. o Included a note that the attempts to retrieve regular IPv4 and IPv6 addresses by a recursive DNS server could be initiated simultaneously to reduce latency. o Elaborated on the mapping management for the case when two IPv4- only hosts want to communicate with the same remote IPv6-only Vogt & Durand Expires April 29, 2010 [Page 23] Internet-Draft Virtual IPv6 Connectivity October 2009 peer. In this case, the same mapping should be used for both communication sessions to reduce the number of virtual IPv4 addresses needed. o Further review comments on abstract and introduction were already addressed by the document revision from version 00 to version 01. Authors' Addresses Christian Vogt Ericsson Research, NomadicLab Hirsalantie 11 02420 Jorvas Finland Email: christian.vogt@ericsson.com Alain Durand Comcast 1500 Market Street Philadelphia, PA 19102 USA Email: alain_durand@cable.comcast.com Vogt & Durand Expires April 29, 2010 [Page 24]