Network Working Group Christian Vogt Internet-Draft Ericsson Expires: January 14, 2010 Alain Durand Comcast July 13, 2009 Virtual IPv6 Connectivity for IPv4-Only Networks draft-vogt-durand-virtual-ip6-connectivity-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Although the impetus to invest in interworking between IP versions 4 and 6 is initially on the side of early IPv6 adopters, more Vogt & Durand Expires January 14, 2010 [Page 1] Internet-Draft Virtual IPv6 Connectivity July 2009 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 to enable 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. IP Protocol Translation . . . . . . . . . . . . . . . . . . . 7 5. Discovery of Virtual IP Addresses . . . . . . . . . . . . . . 12 6. Multi-Homing Support . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Vogt & Durand Expires January 14, 2010 [Page 2] Internet-Draft Virtual IPv6 Connectivity July 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 January 14, 2010 [Page 3] Internet-Draft Virtual IPv6 Connectivity July 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 make IPv4-only hosts reachable via an IPv6 address from peers on the Internet. IPv4 addresses of IPv4-only hosts are statically mapped to "virtual IPv6 addresses", retrievable by IPv6 peers via the DNS or DNSSEC. IPv6 addresses of peers on the Internet are dynamically mapped to "virtual IPv4 addresses", retrievable by IPv4-only hosts 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 IP protocol translators, placed on border links of the IPv4-only network, to translate packets exchanged with remote IPv6 peers. 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 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 peers to hosts in the IPv4-only network. Furthermore, the IPv4-only network has authoritative and recursive DNS servers that can return, Vogt & Durand Expires January 14, 2010 [Page 4] Internet-Draft Virtual IPv6 Connectivity July 2009 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 correspondent host are always destined to a virtual IP address when initially dispatched by the sender. Virtual IP addresses route to an IP protocol translator, which performs three tasks with a received packet: 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 [###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. The pair of a virtual IP address and the represented regular IP address is called a "mapping". Mappings are used in IP protocol translators and DNS servers to enable the consistent translation of packets between IP versions, as well as the retrieval of virtual IP addresses. 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 preprovisioning of the mappings in IP protocol Vogt & Durand Expires January 14, 2010 [Page 5] Internet-Draft Virtual IPv6 Connectivity July 2009 translators and authoritative DNS servers. On the other hand, mappings between IPv6 addresses and virtual IPv4 addresses are dynamic and on-demand. 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 created during the establishment of the corresponding communication session. This process is triggered by a recursive DNS server when receiving a query for an IPv6-only peer's DNS name from an IPv4-only host. Mappings between IPv6 addresses and virtual IPv4 addresses 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. 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 Vogt & Durand Expires January 14, 2010 [Page 6] Internet-Draft Virtual IPv6 Connectivity July 2009 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. 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. Vogt & Durand Expires January 14, 2010 [Page 7] Internet-Draft Virtual IPv6 Connectivity July 2009 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. 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 Vogt & Durand Expires January 14, 2010 [Page 8] Internet-Draft Virtual IPv6 Connectivity July 2009 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 IP addresses. For example, the route to virtual IPv4 addresses within an IPv4-only network may be a default route. Figure 2 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 2: 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, Vogt & Durand Expires January 14, 2010 [Page 9] Internet-Draft Virtual IPv6 Connectivity July 2009 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: 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 5. 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 Vogt & Durand Expires January 14, 2010 [Page 10] Internet-Draft Virtual IPv6 Connectivity July 2009 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. 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 3: Mapping state creation and packet translation for a communication initiated by an IPv6 correspondent host Figure 3 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 Vogt & Durand Expires January 14, 2010 [Page 11] Internet-Draft Virtual IPv6 Connectivity July 2009 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 figure. 5. Discovery of Virtual IP Addresses Virtual IPv6 Connectivity requires that the initiator of a new communication obtains a virtual IP address for its peer: An IPv6 correspondent host intending to reach an IPv4 host must obtain a virtual IPv6 address for the IPv4 host; an IPv4 host intending to reach an IPv6 correspondent host must obtain a virtual IPv4 address for the IPv6 correspondent host. To support the discovery of virtual IP addresses, Virtual IPv6 Connectivity makes virtual IPv4 and IPv6 addresses available via the DNS. This section explains the configuration and operational extensions for recursive and authoritative DNS name servers in an IPv4-only network that are necessary for this. 5.1. Discovery of Virtual IPv6 Addresses For an IPv6 correspondent host to obtain via the DNS the virtual IPv6 addresses of an IPv4 host in an IPv4-only network with Virtual IPv6 Connectivity, the authoritative DNS name servers of the IPv4-only network must be configured with AAAA records for the IPv4 host's virtual IPv6 addresses. Since the virtual IPv6 address corresponding to each IPv4 address is well defined, authoritative DNS servers can automatically generate an AAAA record for each A record they maintain. Thus, whenever a host in the IPv4-only network has an IPv4 address in the DNS, a virtual IPv6 address for this host is retrievable via the DNS as well. The retrieval of virtual IPv6 addresses via DNS hence does not differ from the retrieval of regular IP addresses. Vogt & Durand Expires January 14, 2010 [Page 12] Internet-Draft Virtual IPv6 Connectivity July 2009 IPv6 correspondent authoritative DNS name 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 4: Discovery of virtual IPv6 addresses via DNS Figure 4 shows the resolution of an IPv4 host's name into a virtual IPv6 address. In this example, the IPv4 host's name is "host.v4.net". This resolves into the regular IPv4 address a.b.c.d, which in turn maps to the virtual IPv6 address 2001:DB8:ABC::a.b.c.d. The message exchange in the figure begins where the IPv6 correspondent host queries an authoritative DNS name server from the IPv4-only network for a resource record of type AAAA associated with host name "host.v4.net". The authoritative DNS name server responds with a DNS reply that contains a type-AAAA resource record with the virtual IPv6 address 2001:DB8:ABC::a.b.c.d. 5.2. Discovery of Virtual IPv4 Addresses IPv4 hosts in an IPv4-only network with Virtual IPv6 Connectivity must be able to obtain a virtual IPv4 address when resolving the host name of a remote IPv6 correspondent host via DNS. Virtual IPv4 addresses are provisioned by a recursive DNS name server in the IPv4- only network when a local IPv4 host queries for an IPv4 address associated with an IPv6 correspondent host's name. The recursive DNS name server then retrieves resource records of type AAAA associated with the correspondent host's name, maps the regular IPv6 addresses from those resource records onto virtual IPv4 addresses, and returns the virtual IPv4 addresses in resource records of type A to the requesting IPv4 host. Different than virtual IPv6 addresses, virtual IPv4 addresses cannot be provisioned directly by the DNS name server that is authoritative for the IPv6 correspondent host. Since virtual IPv4 addresses are mapped to regular IPv6 addresses in dynamic manner, a DNS name server handing out virtual IPv4 addresses must necessarily coordinate with the entity in the IPv4-only network that maintains the virtual IPv4 addresses. Such coordination is infeasible for a correspondent host's authoritative DNS name server, since this is in general under a different administration than the IPv4-only network. Vogt & Durand Expires January 14, 2010 [Page 13] Internet-Draft Virtual IPv6 Connectivity July 2009 The operation of a recursive DNS name server in an IPv4-only network with Virtual IPv6 Connectivity more specifically proceeds as follows: o Upon receiving a DNS query from a local IPv4 host for resource records of type A associated with a correspondent host's name, the recursive DNS name server first attempts to retrieve regular IPv4 addresses of the correspondent host. It thus seeks to directly obtain the requested resource records of type A. This is the standard operation of a recursive DNS name server. o If the recursive DNS name server receives a DNS reply with a resource record of type A, it returns the DNS reply unchanged to the resolving IPv4 host. The correspondent host in this case has a regular IPv4 address, and it is not necessary to allocate a virtual IPv4 address for the correspondent host. o If the recursive DNS name server fails to receive a DNS reply with a resource record of type A, the correspondent host cannot be reached at a regular IPv4 address. The recursive DNS name server in this case attempts to retrieve resource records of type AAAA associated with the correspondent host's name. o If the recursive DNS name server receives a DNS reply with a resource record of type AAAA, the correspondent host can be reached at one or more regular IPv6 addresses. These need to be presented to the resolving IPv4 host in form of virtual IPv4 addresses. The recursive DNS name server maps each of the correspondent host's regular IPv6 addresses onto a separate virtual IPv4 address in coordination with the IP protocol translator to which these virtual IPv4 addresses route. The recursive DNS name server then synthesizes a DNS reply with one resource record of type A for each virtual IPv4 address, and returns this DNS reply to the resolving IPv4 host. o If the recursive DNS name server fails to receive a DNS reply with resource records of either type A or type AAAA, it returns an error notification to the resolving IPv4 host. The correspondent host is in this case unreachable from the IPv4 host. Figure 5 illustrates the operation of a recursive DNS name server in an IPv4-only network with Virtual IPv6 Connectivity. In the figure, an IPv4 host on the left requests a recursive DNS name server in the middle to resolve an IPv6 correspondent host's name into an IPv4 address. The name of the correspondent host is "host.v6.net" in this case, and this is associated with a single resource record of type AAAA for IPv6 address 2001:DB8:BCD::X:Y:Z. The resolving IPv4 host initiates the procedure with a DNS query to the recursive DNS name server, requesting resource records of type A associated with Vogt & Durand Expires January 14, 2010 [Page 14] Internet-Draft Virtual IPv6 Connectivity July 2009 "host.v6.net". The DNS query is not for resource records of type AAAA since only IPv4 addresses are of use for the IPv4 host. The recursive DNS name server first processes the DNS query unchanged, so it tries to retrieve resource records of type A from the DNS name server that is authoritative for the correspondent host, as represented on the right of Figure 5. This fails because the correspondent host does not have an IPv4 address. In a second attempt, the recursive DNS name server queries for resource records of type AAAA. This is successful; the recursive DNS name server receives a resource record with IPv6 address 2001:DB8:BCD::X:Y:Z. The recursive DNS name server then coordinates with an IP protocol translator in the IPv4-only network in order to create 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 5, this virtual IPv4 address is 10.u.v.w. The recursive DNS name server finally returns a DNS reply to the resolving IPv4 host that contains a resource record of type A containing the virtual IPv4 address 10.u.v.w. Vogt & Durand Expires January 14, 2010 [Page 15] Internet-Draft Virtual IPv6 Connectivity July 2009 IPv4 host recursive DNS DNS name 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 5: Discovery of virtual IPv4 addresses via DNS 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: Vogt & Durand Expires January 14, 2010 [Page 16] Internet-Draft Virtual IPv6 Connectivity July 2009 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 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 Vogt & Durand Expires January 14, 2010 [Page 17] Internet-Draft Virtual IPv6 Connectivity July 2009 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. 7. Security Considerations No security considerations yet; to be written down. 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgment Many ideas in Virtual IPv6 Connectivity were originally proposed in Vogt & Durand Expires January 14, 2010 [Page 18] Internet-Draft Virtual IPv6 Connectivity July 2009 2002 by Alain Durand [draft-durand-ngtrans-nat64-nat46]. This document was generated using the xml2rfc tool. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 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 January 14, 2010 [Page 19]