One document matched: draft-wing-behave-dns64-config-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY rfc4361 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml">
<!ENTITY I-D.ietf-behave-dns64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-dns64.xml">
<!ENTITY I-D.boucadair-behave-dns-a64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-behave-dns-a64.xml">
<!ENTITY rfc4242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml">
<!ENTITY rfc3646 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml">
<!ENTITY rfc3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
<!ENTITY rfc3513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3513.xml">
<!ENTITY rfc3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY rfc6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY I-D.ietf-behave-ftp64 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-ftp64.xml">
<!ENTITY I-D.wing-behave-learn-prefix SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-behave-learn-prefix.xml">
<!ENTITY I-D.savolainen-mif-dns-server-selection SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.savolainen-mif-dns-server-selection.xml">
<!ENTITY I-D.arifumi-6man-rfc3484-revise SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arifumi-6man-rfc3484-revise.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-behave-dns64-config-03"
ipr="trust200902">
<front>
<title abbrev="IPv6-only & Dual-Stack with DNS64">IPv6-only and Dual
Stack Hosts on the Same Network with DNS64</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date />
<workgroup>BEHAVE Working Group</workgroup>
<abstract>
<t>Some networks are expected to support IPv4-only, dual-stack, and
IPv6-only hosts at the same time. Such networks also want to IPv6/IPv4
translation for the IPv6-only host so it can access servers on the IPv4
Internet. On such a network, the synthesized AAAA responses from a DNS64
can cause traffic to be translated. This document describes a solution
to avoid that translation when the application uses DNS.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>In order to access IPv4 servers, an IPv6-only host needs to use an
IPv6/IPv4 translator. Typically, the IPv6-only host performs a DNS query
to a DNS64 recursive resolver, which synthesizes an AAAA when necessary.
However, if a dual-stack host uses that same DNS64 recursive resolver
and normal <xref target="RFC3484">address selection rules</xref>, the
dual-stack host will send traffic through the IPv6/IPv4 translator when
such traffic could have been sent using IPv4. Thus, as an optimization,
it is desirable that a dual-stack host avoid IPv6/IPv4 translation.</t>
<t>Note: If the dual-stack host's IPv4 traffic is being NATted the
difference is NAT44 versus NAT64, so the performance and saleability
concern is nearly identical. However, at least one application breaks
when translated between IP address families unless special measures are
taken <xref target="I-D.ietf-behave-ftp64"></xref>. The IETF should
decide if it is worthwhile to avoid NAT64 for dual-stack hosts that are
connected to a network operating a DNS64.</t>
<t><list style="empty">
<t>Note: Windows XP can only be configured with IPv4 DNS servers
<xref target="XP-DNS"></xref>. This means a Windows XP host is
always dual-stack and requires an IPv4 address in order to send its
DNS queries. While it is possible to work around this issue by
running BIND on the Windows XP device itself, this is complex. Thus,
Windows XP should not be considered a viable operating system to
join an IPv6-only network.</t>
</list></t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t>"IPv4-only" means a host that has only IPv4 address(es) assigned to
its interface(s). "Dual-stack" means a host that has an IPv4 address and
an IPv6 address assigned to its interface(es). "IPv6-only" means a host
that has only IPv6 address(es) assigned to its interface(s).</t>
</section>
<section title="Mechanism">
<t>It has been observed that some common operating systems, when
configured as dual-stack, will successfully use an IPv4-mapped address
(and send an IPv4 packet). But when configured as IPv6-only, they will
not successfully use an IPv4-mapped address (because they lack an IPv4
address) <xref target="experiment"></xref>.</t>
<t>We take advantage of this by configuring the 'normal' DNS server
using an IPv4-mapped IPv6 address (that is, an IPv6 address starting
with ::ffff:/96), and configuring the DNS64 server using a normal IPv6
address.</t>
<t>DNS servers are used in the order listed <xref
target="RFC3646"></xref>, so a dual-stack host will use the 'normal' DNS
server (which is accessible over IPv4) and an IPv6-only host will be
unable to use that 'normal' DNS server and will use the next server on
its list.<list style="empty">
<t>Note: Non-compliant IPv6 stacks might send a packet to the
IPv4-mapped IPv6 address (::ffff:c000:0201, using the example
below). To deal with such non-compliant IPv6 implementations the
network can filter (drop) traffic to that IPv6 address, which will
force those stacks to timeout when attempting to contact the first
DNS server and fall back to using the second DNS server.</t>
</list></t>
<figure>
<preamble>For example, a dual-stack host and an IPv6-only host would
be configured with the following DNS servers, in this order, where the
first one is the normal DNS server (192.0.2.1) and the second one is
the DNS64 server (2001:db8:dddd::1234)</preamble>
<artwork align="center"><![CDATA[
::ffff:192.0.2.1 # 'normal' DNS server
2001:db8:dddd::1234 # DNS64 server
]]></artwork>
<postamble></postamble>
</figure>
<t>This technique requires no change to host operating systems or host
applications.</t>
<t>When transitioning from dual-stack to IPv6-only, nothing needs to
occur - the higher-priority DNS server (with the IPv4-mapped IPv6
address) will become inaccessible and the DNS client will fail over to
the next-higher priority DNS server (which is the DNS64 server). This
does mean the host will take a few extra sections to fully initialize,
as it will have to timeout its attempts to communicate with the first
DNS server.</t>
<t>When transitioning from IPv6-only to dual-stack, nothing
automatically causes the host to start querying the 'normal' DNS server.
Thus, a host that transitions from IPv6-only to dual-stack will continue
to query the DNS64 until the host's stack re-initializes.</t>
<t><list style="empty">
<t>Operating System Note: On Linux systems, this technique is not
effective if the sysctl net.ipv6.bindv6only is set, as setting this
parameter causes dual-stack systems to not send packets to
IPv4-mapped IPv6 addresses.</t>
</list></t>
<t>If the first DNS server is unavailable (e.g., link failure or DNS
server failure) and the host's resolver times out, it will try the
second DNS server, which is a DNS64 server. This is unavoidable with
this technique. Thus, it is important that a robust infrastructure be
used for the DNS servers, especially the first DNS server.</t>
</section>
<section anchor="securityconsiderations" title="Security Considerations">
<t>TBD.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Mohamed Boucadair, Marcelo Braun, Ralph Droms, Dave Thaler,
Bernie Volz, and Andrew Yourtchenko for their review comments.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3315;
&rfc2131;
&rfc4361;
&I-D.ietf-behave-dns64;
&rfc4242;
&rfc3646;
&rfc3484;
</references>
<references title="Informative References">
&rfc6052;
&I-D.ietf-behave-ftp64;
&I-D.wing-behave-learn-prefix;
&I-D.savolainen-mif-dns-server-selection;
&rfc3513;
&I-D.arifumi-6man-rfc3484-revise;
<reference anchor="mif"
target="http://www.ietf.org/dyn/wg/charter/mif-charter">
<front>
<title>Multiple Interfaces Working Group</title>
<author fullname="IETF" surname="IETF">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="6man"
target="http://www.ietf.org/dyn/wg/charter/6man-charter">
<front>
<title>IPv6 Maintenance Working Group</title>
<author fullname="IETF" surname="IETF">
<organization></organization>
</author>
<date year="2009" />
</front>
</reference>
<reference anchor="XP-DNS"
target="http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_config_items.mspx">
<front>
<title>Windows XP: IPv6 configuration items</title>
<author fullname="Microsoft" surname="Microsoft">
<organization></organization>
</author>
<date month="5" year="2005" />
</front>
</reference>
<reference anchor="experiment"
target="http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html">
<front>
<title>practical issues with using v4-mapped addresses for
nat64</title>
<author fullname="Marcelo Bagnulo Braun" surname="Braun">
<organization></organization>
</author>
<date month="Jul" year="2008" />
</front>
</reference>
&I-D.boucadair-behave-dns-a64;
</references>
<section title="Other Techniques">
<t><list style="empty">
<t>[Editor's Note: This section will be removed in a later version
of this document. It is kept, in this appendix, for reference.]</t>
</list></t>
<t>This section discusses other techniques which had been considered to
avoid DNS64/NAT64 by dual-stack hosts.</t>
<section title="New DHCP option for 'normal' DNS server">
<t>Another approach, which requires modification of dual-stack hosts
which want to avoid the DNS64, is to introduce a new DHCP option.</t>
<t>This approach feels a little backwards at first. The idea is to
support unmodified hosts (which might be dual-stack but might be
IPv6-only) by placing DNS64 servers into the normal <xref
target="RFC3646">DHCPv6 option for DNS servers</xref>. Then, place the
'normal' DNS servers into a *new* DHCPv6 option.</t>
<section title="Host Transition">
<t>TBD.</t>
</section>
<section title="Advantages and Disadvantages">
<t>Disadvantages:<list style="symbols">
<t>If dual-stack hosts want to avoid NAT64, they need to be
modified to understand this new DHCP option. If they aren't
modified, they will use NAT64.</t>
</list></t>
</section>
</section>
<section title="Modify Host's Address Selection Rules">
<t>The <xref target="RFC3484">default address selection rules</xref>
prefer IPv6 over IPv4. This means, for a dual-stack host, that IPv6
will be preferred (if available) over IPv4. If a dual-stack host is
configured to use a DNS64 server, that DNS64 server will synthesize an
AAAA response if there is an A record. Thus, the dual-stack host will
always use IPv6 if a DNS lookup was involved, even if IPv4 could have
been used more optimally. <list style="empty">
<t>Note: If both a NAT44 and NAT64 are deployed on the same
network, roughly the same inefficiency occurs (that is, NAT state
is created). However, it is generally considered better to perform
NAT44 than NAT64, because NAT64 translates between IP address
families which can have side effects (e.g., FTP).</t>
</list></t>
<t>To avoid this, the host's <xref target="RFC3484">default address
selection rules</xref> can be modified so that IPv4 is preferred over
the IPv6/IPv4 translator's prefix. At the same time, native IPv6 can
still be preferred over IPv4. This is accomplished by adding the
network's IPv6/IPv4 translator's prefix as the lowest Precedence in
the address selection rules.</t>
<t>If the IPv6/IPv4 translator's prefix is the IANA-assigned
well-known prefix (64:FF9B::/96, as assigned in <xref
target="RFC6052"></xref>), this can be hard-coded or easily scripted
into the system startup. However, if the IPv6/IPv4 translator's prefix
is a network-specific prefix (NSP, as described in <xref
target="RFC6052"></xref>), the default address selection rules can be
modified only after the host learns its currently-connected network's
IPv6/IPv4 translator's prefix (e.g., using <xref
target="I-D.wing-behave-learn-prefix"></xref>).</t>
<t>On some operating systems, the address selection rules can be
configured using a command line utility (e.g., Windows, FreeBSD),
without new software in the host's IP stack. Other operating systems
are not as accommodating of this solution (see <xref
target="address-limitations"></xref>).</t>
<t><list style="empty">
<t>Note: it may be desirable to create a standard to adjust a
host's address selection rules based on the translator's prefix.
This is a topic for the <xref target="6man">IPv6 maintenance
working group</xref>. This automatic mechanism may involve
modifications to the host's IP stack, depending on how the IETF
chooses to standardize such a mechanism. FOR EXAMPLE, it may be
useful to consider <xref
target="I-D.wing-behave-learn-prefix"></xref> (which proposes
using either DNS or DHCPv6) in conjunction with adjusting the
host's address selection rules.</t>
</list></t>
<section title="Host Transition">
<t>An IPv6-only and a dual-stack host can both be configured with
the same address selection rules (namely, both can add the network's
translator as the lowest Precedence). This is because the IPv6-only
host will never use IPv4 (because it lacks an IPv4 address) and will
thus fall through and use the IPv6 address synthesized by the DNS64
containing the IPv6/IPv4 translator's prefix (that is, as shown in
the examples, the IPv6-only host will use the Precedence 3 entry in
the default policy table). The dual-stack host, if it receives an
AAAA response, will prefer use IPv6; if it receives only an A
response, it will prefer to use IPv4 (using Precedence 10 for
IPv4-mapped addresses defined in Section 2.5.4 of <xref
target="RFC3513"></xref>).</t>
</section>
<section anchor="address-limitations"
title="Limitations and Advantages">
<t>The following limitations are observed: <list style="symbols">
<t>OSX does not implement a <xref target="RFC3484"></xref> or
<xref target="RFC3484"></xref>-like policy table.</t>
<t>Some applications implement their own address selection
rules, effectively ignoring the OS's address selection
rules.</t>
</list></t>
<t>The following advantages are observed: <list style="symbols">
<t>Causes IPv4 to be preferred over IPv6/IPv4 translator
addresses, even if DNS was not used to obtain the IPv4 or IPv6
address (e.g., applications which do not use DNS).</t>
</list></t>
</section>
<section title="Examples">
<figure>
<preamble>For example, if a network is using the WKP 64:FF9B::/96
<xref target="RFC6052"></xref> and a host is using the new default
policy table from <xref
target="I-D.arifumi-6man-rfc3484-revise"></xref> (which added
Precedence 5 for Teredo), the host's new policy table would
contain one new entry with Precedence 3, as shown
below:</preamble>
<artwork align="center"><![CDATA[
Prefix Precedence Label
::1/128 50 0 # localhost
::/0 30 2 # IPv6 native
2002::/16 20 3 # 6to4
::ffff:0:0/96 10 4 # IPv4-mapped
2001::/32 5 5 # Teredo
64:FF9B::/96 3 6 # 6/4 translator's prefix
]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble>As another example, if a network has the prefix
2001:0DB8::/32 and the NAT64 is using the Network-Specific Prefix
(NSP) 2001:0DB8:AAAA::/96, and the host is using the new default
policy table from <xref
target="I-D.arifumi-6man-rfc3484-revise"></xref> (which added
Precedence 5 for Teredo), the host's new policy table would
contain one new entry with Precedence 3, as shown
below:</preamble>
<artwork align="center"><![CDATA[
Prefix Precedence Label
::1/128 50 0 # localhost
::/0 30 2 # IPv6 native
2002::/16 20 3 # 6to4
::ffff:0:0/96 10 4 # IPv4-mapped
2001::/32 5 5 # Teredo
2001:0DB8:AAAA::/96 3 6 # 6/4 translator's prefix
]]></artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section title="Indicating AAAA synthesis using DNS response flag">
<t>Dacheng Zhang's idea.</t>
</section>
<section title="New A64 record">
<t><xref target="I-D.boucadair-behave-dns-a64"></xref></t>
</section>
<section title="Use DHCP to Assign Appropriate DNS Server">
<t><list style="empty">
<t>Note: due to the limitations of this solution (see <xref
target="dhcp_limitations"></xref>), it may have little or no
value.</t>
</list>To avoid unnecessary traffic through a translator, it is
desirable to configure IPv4-only and dual-stack hosts with a 'normal'
DNS recursive resolver.</t>
<t>However, it is necessary to configure IPv6-only hosts with a <xref
target="I-D.ietf-behave-dns64">DNS64</xref> recursive resolver so
those hosts can use an IPv6/IPv4 translator and access servers on the
IPv4 Internet.</t>
<t>It is difficult to provide different DNS servers to those types of
hosts, because there is no existing protocol that declares a host is
IPv4-only, dual-stack, or IPv6-only.</t>
<t>This document describes how a network's DHCPv4 and DHCPv6 servers,
combined with a <xref target="RFC4361">client-identifiers</xref>
chosen by the host, can determine if a host is IPv4-only, dual-stack,
or IPv6-only, and assign the correct DNS server according to that
determination.</t>
<t><list style="empty">
<t>Note: the DHCP mechanism described in this section have some
overlap with the <xref target="mif">Multiple Interfaces Working
Group</xref> and with <xref
target="I-D.savolainen-mif-dns-server-selection">split-zone
DNS</xref>.</t>
</list></t>
<t>Both an IPv4-only host and a dual-stack host obtain an IPv4 network
address. Today, hosts most commonly obtain an IPv4 address using <xref
target="RFC2131">DHCPv4</xref>. An IPv6-only host does not obtain an
IPv4 address; however, it may be using DHCPv6 to obtain other
information (e.g., NTP servers). The following procedure takes
advantage of that difference to determine if a host is IPv4-only,
dual-stack, or IPv6-only.</t>
<section title="Host Requirements">
<t>The host has the following requirements:<list style="numbers">
<t>if the host uses IPv4, it MUST use DHCPv4 to learn its IPv4
address and its DNS server address(es); and,</t>
<t>if the host uses IPv6, it MUST use DHCPv6 to learn its IPv6
DNS resolver, using the Information-Request message described in
Section 18.1.5 of <xref target="RFC3315"></xref> and using <xref
target="RFC3646"></xref>; and,</t>
<t>the host MUST use <xref
target="RFC4361">client-identifiers</xref> to identify itself to
its DHCP server(s), and MUST use the same client-identifier for
both DHCPv4 and DHCPv6<list style="empty">
<t>Note: This last requirement is stronger than the SHOULD
in Section 6.2 of <xref target="RFC4361"></xref></t>
</list>If the host does not support DHCP authentication, and
acquires/releases its IPv4 address while keeping its IPv6
address, it MUST support the procedure described in <xref
target="host_transition"></xref>; and,</t>
<t>the host MUST support the <xref target="RFC4242">DHCP
Information Refresh Time Option</xref>.</t>
</list></t>
</section>
<section anchor="server-req"
title="DHCPv4 and DHCPv6 Server Requirements">
<t>The DHCPv4 and DHCPv6 servers have the following requirements:
<list style="numbers">
<t>the DHCPv4 and DHCPv6 servers MUST be able to communicate
with each other both <xref
target="RFC4361">client-identifiers</xref> and if an IPv4
address is assigned to that client-identifier; and,</t>
<t>If the DHCP server and the host support DHCP authentication,
the DHCP server MUST support the procedure described in <xref
target="host_transition"></xref>.</t>
<t>MUST support the <xref target="RFC4242">DHCP Information
Refresh Time Option</xref>.</t>
</list></t>
</section>
<section title="DHCP Server Operation">
<t>If the DHCP server first receives a DHCPv4 request for a
particular client-identifier, it responds with the 'normal' DNS
resolver. The DHCPv6 server remembers that RFC4361 client identity
and if the DHCPv6 server sees a DHCPv6 request from that same client
identity, it responds to the DHCPv6 request with a 'normal' DNS
resolver.</t>
<t>If the DHCP server first receives a DHCPv6 request for a
particular client-identifier, it responds with a short <xref
target="RFC4242">information refresh time</xref> (e.g., 30 seconds)
and a DNS64 recursive resolver. <list style="empty">
<t>Note-1: This means that during the short information refresh
time, both a dual-stack host and an IPv6-only will have their
DNS queries processed by the DNS64 recursive resolver. During
that time, both the dual-stack host and the IPv6-only host will
get connectivity to IPv4 servers, but the dual-stack host will
use the IPv6/IPv4 translator until the information refresh time
expires.</t>
<t>Note-2: for discussion: Consider have DHCP server slightly
delay (e.g., 100ms) responding to a DHCPv6 request. This gives a
chance for the DHCPv4 request to be received, thus avoiding the
issue described in Note-1.</t>
</list></t>
<t>After the short information refresh time, the DHCPv6 client will
send a new request. By that time, the DHCPv6 server will have
either: <list style="letters">
<t>have seen a DHCPv4 request from the same RFC4361 host. This
indicates the host supports dual-stack. The DHCP server should
extend the DHCPv6 lease, and provide a 'normal' DNS server
(instead of the DNS64 server).</t>
<t>have not seen a DHCPv4 request from the same RFC4361 host.
This indicates the host is IPv6-only. The DHCP server should
extend the DHCPv6 lease and continue providing the same DNS64
server.</t>
</list></t>
</section>
<section anchor="host_transition" title="Host Transition">
<t>During natural evolution of a network or because of
debugging/troubleshooting, a host might transition between
IPv4-only, dual-stack, or IPv6-only. When the host acquires or
releases its IPv4 address it transitions to needing a different DNS
server; if the host has an IPv4 address, it needs a 'normal' DNS
server and if it does not have an IPv4 address it needs a DNS64
server.</t>
<t>There are two transitions considered, where the host
transitions:<list style="numbers">
<t>from IPv6-only to IPv4-supporting (that is, IPv4-only or
dual-stack),</t>
<t>from IPv4-supporting (that is, IPv4-only or dual-stack) to
IPv6-only.</t>
</list></t>
<t>When doing (1), the DHCPv4 server will provide a 'normal' DNS
server (because the DHCPv4 server sees the same client-identifier as
seen by the DHCPv6 server). So case (1) is solved.</t>
<t>However, when doing (2), the host is giving up its IPv4 address
and is currently using a normal DNS server, but needs to be told to
use a DNS64 server instead. There are two mechanisms to provide that
function, based on the network and host's support of DHCP
authentication (Section 19.1.1 of <xref target="RFC3315"></xref>)
<list style="numbers">
<t>with DHCP authentication: When a certain client identifier
loses or acquires its IPv4 address and also has an IPv6 address,
the DHCPv6 server MUST send a <xref target="RFC3315">DHCP
RECONFIGURE message</xref> to the host and SHOULD include the
Option Request option indicating the DNS server information has
changed. The RECONFIGURE message triggers the host to send a new
Information-Request message to the DHCPv6 server.</t>
<t>without DHCP authentication: the host, when keeping its IPv6
address and releasing its IPv4 address, MUST also issue a new
DHCPv6 Information-Request message to the DHCPv6 server.</t>
</list>In both cases, the Information-Request message causes the
DHCPv6 server to reply with a DNS64 recursive resolver, as discussed
in <xref target="server-req"></xref>.</t>
</section>
<section anchor="dhcp_limitations"
title="Advantages and Disadvantages">
<t>Advantages: <list style="symbols">
<t>Dual-stack applications, which perform DNS lookups, will
effectively avoid NAT64 when using the 'normal' DNS server.</t>
</list></t>
<t>Disadvantages: <list style="symbols">
<t>A network with mixed IPv4-only/dual-stack hosts and IPv6-only
hosts needs to have a mix of DNS configurations for those hosts.
Thus, mechanisms that advertise the same DNS servers to all
hosts cannot be used on such networks (e.g., IPv6 router
advertisements).</t>
<t>If separate networks operate DHCPv4 and DHCPv6 (e.g., as with
Dual-Stack Lite where the ISP operates DHCPv4 and the customer
premise router operates DHCPv6), it is likely impossible for the
DHCPv4 and DHCPv6 servers to communicate necessary information
with each other.</t>
<t>Windows does not support <xref target="RFC4361"></xref>.</t>
<t>OSX does not support DHCPv6.</t>
</list></t>
</section>
</section>
<section title="New DHCP option for DNS64 server">
<t>Another approach, which requires modification of IPv6-only hosts
which need to use the DNS64, is to introduce a new DHCP option.</t>
<t>The idea is to support unmodified dual-stack hosts (which use the
normal DNS server provided via <xref target="RFC3646"></xref>), but to
modify IPv6-only hosts to look for the DNS64 server in a newly-defined
DHCPv6 option.</t>
<section title="Advantages and Disadvantages">
<t>Disadvantages:<list style="symbols">
<t>Requires modifying IPv6-only hosts, and without this
modification they won't work at all with a DNS64.</t>
</list></t>
</section>
</section>
<section title="New DHCP option to identify dual-stack host">
<t>Dacheng Zhang's idea.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:43:11 |