One document matched: draft-vogt-durand-virtual-ip6-connectivity-03.txt
Differences from draft-vogt-durand-virtual-ip6-connectivity-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 22:38:56 |