Framework for
accessing IPv6 content for IPv4-only clientsHrvatski TelekomZagrebCroatiabranimir.rajtar@t.ht.hrDeutsche Telekom AGBonnGermanyian.farrer@telekom.deT-Mobile CZPragueCzech Republicales.vizdal@t-mobile.czCERNET Center/Tsinghua UniversityBeijingChinaxing@cernet.edu.cnCERNET Center/Tsinghua UniversityBeijingChinacongxiao@cernet.edu.cn
Transport
Behave WGWith the expansion of IPv6 usage and content available on IPv6, it is
important that clients with legacy (i.e. non IPv6-capable) operating
systems are able to access such content.This document describes a method for achieving this, including how
the method could be implemented in real-world scenarios.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 RFC 2119.At the time of writing, IPv6 is still not widely deployed. There are
several reasons for this, one of which is that IPv4-only operating
systems are still commonplace with end-users and account for a large
fraction of overall Internet traffic.With the growth of IPv6 traffic, servers supporting only IPv6 are
appearing on the Internet. An approach for enabling and IPv4-only
clients to access this content is described below.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.The server hosting the content MUST have a valid AAAA
recordThe client MUST support IPv4 only. 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 resolved by a dedicated appliance,
i.e. a caching nameserver.All traffic between the client and the server MUST be routed
through a device capable of performing translation between IPv4
and IPv6, as described in and .It is feasible that requirements (4) and (5) can be combined
in one device and managed by the service provider.That would simplify
operations and remove the need for a control-plane protocol between
the two devices. describes multiple scenarios for IPv4/IPv6
translation. This document is mainly concerned with Scenario 4: An
IPv4 Network to the IPv6 Internet, but is also applicable to Scenario
6 (An IPv4 Network to an IPv6 Network). This scenario is not covered
in this memo and can be elaborated in future documents, as necessary.
Scenario 2, which faces similar challenges (The IPv4 Internet to an
IPv6 Network), is covered by .User end-device, typically a personal
computer or similar.Caching nameserver which proxies DNS
queries from the client.Translation device which translates
incoming IPv4 traffic.Device which holds content on an
IPv6-only network.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 ipv6.example.com
which is running on an IPv6-only server.The customer types in "ipv6.example.com" into his web browser and
initiaties the request for the web page.The client operating system initiates a DNS query for
"ipv6.example.com". Since the client uses IPv4, the query is for an
A record.The DNS proxy receives the A record query and assumes the client
is not IPv6 capable. Therefore, it initiates a DNS query for A and
AAAA records for "ipv6.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 "ipv6.example.com" pointing at an un-used IPv4 address from the
private address space (as described in ).The private IPv4 address and the resolved IPv6 address of
"ipv6.example.com" must be kept in the translation table of the
NAT46 translator. 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
translator is out of the scope of this document. In the case the
translator and the DNS proxy are functions of the same device, the
logic is simplified.All IPv4 traffic from the client to "ipv6.example.com" will be
translated to IPv6 as described in . Unlike
NAT-PT described in (moved to Historic
Status by ), the translation is a learned
state and not a session triggered state. The destination address of
the translated IPv6 packet will be the resolved AAAA record of
"ipv6.example.com", while the source IPv6 address will be created
according to . The IPv6 prefix used to
create the source IPv6 address must be globally unique and allocated
to the device. If there are more IPv6 prefixes on the device,
defining which one will be used is out of the scope of this
document. The IPv4 address used to create the source IPv6 address is
the address of the client.Return IPv6 traffic will be translated by the same device as the
outgoing traffic, using IPv6 to IPv4 translation analogous to the
previous step. The source IPv4 address will 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.In this example, the client is located behind a home gateway and is
delegated an IPv4 address of 192.168.1.3. The home gateway is acting
as a DNS proxy and as a NAT46 translator.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.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.IP/ICMP Translation AlgorithmAddress Allocation for Private InternetsIPv6 Addressing of IPv4/IPv6 TranslatorsKey words for use in RFCs to Indicate Requirement
LevelsFramework for IPv4/IPv6 TranslationNetwork Address Translation - Protocol Translation
(NAT-PT)Reasons to Move the Network Address Translator - Protocol
Translator (NAT-PT) to Historic Status