One document matched: draft-wing-behave-dns64-config-02.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 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 rfc2373 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2373.xml">
<!ENTITY rfc3056 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml">
<!ENTITY I-D.ietf-behave-address-format SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-address-format.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">
<!ENTITY xml2rfcversion SYSTEM "/xml2rfc/version.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-02"
ipr="trust200902">
<front>
<title abbrev="DNS64 Resolvers and Dual-Stack Hosts">DNS64 Resolvers and
Dual-Stack Hosts</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 year="2010" />
<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 and analyzes
several solutions to avoid that translation.</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 scalability
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="Procedures to support IPv6-only and dual-stack hosts with DNS64">
<t>Several solutions are discussed in this section, in roughly the order
of preference (as determined by the author).</t>
<section title="IPv4-Mapped Address for 'normal' DNS server">
<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 could 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>Because <xref target="RFC3646"></xref> says the DNS servers are
used in the order listed, a dual-stack host will use the 'normal' DNS
server 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.</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:</preamble>
<artwork align="center"><![CDATA[
::ffff:192.0.2.1 # 'normal' DNS server (usable only by
dual-stack host. Not usable by IPv6-only
host)
2001:0DB8:DDDD::1234 # DNS64 server
]]></artwork>
<postamble></postamble>
</figure>
<section title="Host Transition">
<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 failover
to the next-higher priority DNS server (which is the DNS64
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>
</section>
<section title="Advantages and Disadvantages">
<t>Advantages:<list style="symbols">
<t>No change to hosts.</t>
<t>On Linux systems, is not effective if the sysctl net.ipv6.bindv6only
is set, as this causes dual-stack systems to not send packets to
IPv4-mapped IPv6 addresses.</t>
</list></t>
<t>Disadvantages:<list style="symbols">
<t>Seems confusing to configure.</t>
<t>Can we rely on IPv6-only hosts allowing IPv4-mapped IPv6
addresses to be configured as their DNS servers? </t>
</list></t>
</section>
</section>
<section title="Disable DNS64 Functions in DNS Query">
<t>A dual-stack host does not need synthesized AAAA records, and does
not need to use the network's NAT64. So, a dual-stack host could send
a DNS query to a DNS64 requesting no synthesized AAAA records. This
allows both dual-stack and IPv6-only hosts to be configured with a
DNS64.</t>
<t>To request no AAAA synthesis, the DNS query sets both the DO bit
("I understand DNSSEC") and the CD bit ("I will do DNSSEC
validation"). When the DNS64 receives a query with those bits set, it
does not synthesize an AAAA response (because doing so would break
DNSSEC validation).</t>
<section anchor="dnssec_host_transition" title="Host Transition">
<t>If host transitions from dual-stack to IPv6-only, it would need
to perform its own DNS64 function (which requires it know the prefix
of its NAT64) or would have to not set the DO and CD bits in DNS
queries. Likewise, if a host transitions from IPv6-only to
dual-stack, it needs to know to start sending DNS queries with the
DO and CD bits set.s</t>
</section>
<section title="Advantages and Disadvantages">
<t>Advantages:<list style="symbols">
<t>Simple</t>
</list></t>
<t>Disadvantages:<list style="symbols">
<t>Requires dual-stack host support DNSSEC validation.</t>
<t>Requires host support <xref
target="dnssec_host_transition"></xref>.</t>
<t>There are security implications if the DNS client is lying
and is not, in fact, going to perform its own DNSSEC
validation.</t>
</list></t>
</section>
</section>
<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="I-D.ietf-behave-address-format"></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="I-D.ietf-behave-address-format"></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="RFC2373"></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="I-D.ietf-behave-address-format"></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="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>
<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>
<t>This document was produced using version &xml2rfcversion; of
XML2RFC.</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">
&I-D.ietf-behave-address-format;
&I-D.ietf-behave-ftp64;
&I-D.wing-behave-learn-prefix;
&I-D.savolainen-mif-dns-server-selection;
&rfc2373;
&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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:45:32 |