Framework for accessing IPv6 content for IPv4-only clients

At the time of writing, IPv6 is still not widely deployed. Several reasons can be named, one of which is the fact that IPv4-only operating systems are still used by many end customers and account for a large fraction of total Internet traffic. Also, with the introduction of Carrier-Grade NAT, exhaustion of IPv4 address space is no longer an issue which would be the key driver of the transition to IPv6. With the growth of IPv6 traffic, servers only supporting IPv6 are appearing on the Internet and IPv4-only clients must be able to access content available on them. The following sections describe a methodology how this can achieved.

To clarify when this approach is applicable, the following requirements can be named: The content must be reachable through IPv6, i.e. the server on which the content is stored must have a valid IPv6 address and a working IPv6 stack. As can be seen later in the document, this in turn implies that the server must have a valid AAAA record. The client must support only IPv4. The other alternative is also that it supports IPv6, but for some reason uses only IPv4 to access content on the Internet. Client's DNS queries must be proxied by a dedicated appliance. All traffic between the client and the server must pass through a device capable of performing translation between IPv4 and IPv6, as described in and . It is feasible that requirements three and four can be combined in one device and managed by the service provider.

As described in , there are multiple scenarios for IPv4/IPv6 translation. This document covers mainly Scenario 4: An IPv4 Network to the IPv6 Internet, but is not limited to be used for the following scenarios as well: Scenario 2: The IPv4 Internet to an IPv6 Network Scenario 6: An IPv4 Network to an IPv6 Network These scenarios are not subject of this draft and can be elaborated in future documents, if deemed necessary.

This section describes how the algorithm works and the roles of every functional element. The steps are in cronological order, and display the scenario when the IPv4 client initiates a request for example.com which is running on an IPv6-only server. The customer types in "example.com" into his web browser and initiaties the request for the web page. The client operating system initiates a DNS query for "example.com". Since the client uses IPv4, the query is for an A record. DNS proxy perceives that the query is for an A resource record only and assumes the client is not IPv6 capable. Therefore, it initiates a DNS query for A and AAAA records for "example.com" to the authorative DNS server. If a DNS response is received with only an AAAA record, the DNS proxy assumes that the server is IPv6-only. (In case the proxy receives both A or AAAA records, or just an A record, the A record is returned to the client and the process ends here.) As a response to the client, the proxy returns a fake A record for "example.com" pointing at an IPv4 address from the private address space (as described in ). The private IPv4 address and the resolved IPv6 address of "example.com" must be kept in translation table at the device which performs the actual translation. The time the translation would stay active in the table would be equal to the TTL field of the DNS response. How the DNS-related information is conveyed from the DNS proxy to the translation device is out of the scope of this document. All IPv4 traffic from the client to "example.com" will be translated to IPv6 as described in . Unlike NAT-PT described in (moved to Historic Status by ), the translation is a configured state and not a session triggered state. The destination address of the translated IPv6 packet will be the resolved AAAA record of "example.com", while the source IPv6 address will be created according to . The IPv4 address and IPv6 prefix used to create the source IPv6 address are out of the scope of this document. Return IPv6 traffic will be translated at the same device as the outgoing traffic, using IPv6 to IPv4 translation analogous to the one described in previous step. The source IPv4 address would be the private IPv4 address given by the DNS proxy to the client, while the destination IPv4 address would be the one of the client.

The typical scenario where such a solution can be used is the home network. The customer can have a broadband service with access to IPv6 Internet, but uses an IPv4-only client. The DNS proxy and the translation device would in that case be the home gateway, which would handle the decision-making process, as well as the translation as well. However, other scenarios can also be foreseable, such as mobile access, business customers, etc. It's applicable to all scenarios where a DNS proxy is used, as well as a default gateway which can act as a translation device.

This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC.