instability disappears. Thus, in the well-known anycast addresses
approach, anycast can and should use the anycast address as a source
unicast (according to RFC 3513 [10]) address of packets of UDP and
TCP responses. With TCP, if a route flips and packets to an anycast
address are routed to a new server, it is expected that the flip is
detected by ICMP or sequence number inconsistency, and that the TCP
connection is reset and retried.
4. Interworking among IPv6 DNS Configuration Approaches
Three approaches can work together for IPv6 host configuration of
RDNSS. This section shows a consideration on how these approaches
can interwork.
For ordering between RA and DHCP approaches, the O (Other stateful
configuration) flag in the RA message can be used [6][28]. If no
RDNSS option is included, an IPv6 host may perform DNS configuration
through DHCPv6 [3]-[5] regardless of whether the O flag is set or
not.
The well-known anycast addresses approach fully interworks with the
other approaches. That is, the other approaches can remove the
configuration effort on servers by using the well-known addresses as
the default configuration. Moreover, the clients preconfigured with
the well-known anycast addresses can be further configured to use
other approaches to override the well-known addresses, if the
configuration information from other approaches is available.
Otherwise, all the clients need to have the well-known anycast
addresses preconfigured. In order to use the anycast approach along
with two other approaches, there are three choices as follows:
1. The first choice is that well-known addresses are used as last
resort, when an IPv6 host cannot get RDNSS information through RA
and DHCP. The well-known anycast addresses have to be
preconfigured in all of IPv6 hosts’ resolver configuration files.
2. The second is that an IPv6 host can configure well-known
addresses as the most preferable in its configuration file even
though either an RA option or DHCP option is available.
3. The last is that the well-known anycast addresses can be set in
RA or DHCP configuration to reduce the configuration effort of
users. According to either the RA or DHCP mechanism, the well-
known addresses can be obtained by an IPv6 host. Because this
approach is the most convenient for users, the last option is
recommended.
Note: This section does not necessarily mean that this document
suggests adopting all of these three approaches and making them
interwork in the way described here. In fact, as a result of further
discussion some approaches may not even be adopted at all.
5. Deployment Scenarios
Regarding the DNS configuration on the IPv6 host, several mechanisms
are being considered by the DNSOP Working Group, such as RA option,
DHCPv6 option, and well-known preconfigured anycast addresses as of
today, and this document is a final result from the long thread. In
this section, we suggest four applicable scenarios of three
approaches for IPv6 DNS configuration.
Note: In the applicable scenarios, authors do not implicitly push any
specific approaches into the restricted environments. No enforcement
is in each scenario, and all mentioned scenarios are probable. The
main objective of this work is to provide a useful guideline for IPv6
DNS configuration.
5.1. ISP Network
A characteristic of an ISP network is that multiple Customer Premises
Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
routers and that each PE connects multiple CPE devices to the
backbone network infrastructure [11]. The CPEs may be hosts or
routers.
If the CPE is a router, there is a customer network that is connected
to the ISP backbone through the CPE. Typically, each customer
network gets a different IPv6 prefix from an IPv6 PE router, but the
same RDNSS configuration will be distributed.
This section discusses how the different approaches to distributing
DNS information are compared in an ISP network.
5.1.1. RA Option Approach
When the CPE is a host, the RA option for RDNSS can be used to allow
the CPE to get RDNSS information and /64 prefix information for
stateless address autoconfiguration at the same time when the host is
attached to a new subnet [6]. Because an IPv6 host must receive at
least one RA message for stateless address autoconfiguration and
router configuration, the host could receive RDNSS configuration
information in the RA without the overhead of an additional message
exchange.
When the CPE is a router, the CPE may accept the RDNSS information
from the RA on the interface connected to the ISP and copy that
information into the RAs advertised in the customer network.
This approach is more valuable in the mobile host scenario, in which
the host must receive at least an RA message for detecting a new
network, than in other scenarios generally, although the
administrator should configure RDNSS information on the routers.
Secure ND [12] can provide extended security when RA messages are
used.
5.1.2. DHCPv6 Option Approach
DHCPv6 can be used for RDNSS configuration through the use of the DNS
option, and can provide other configuration information in the same
message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is
already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or
stateless DHCP [4] is not nearly as complex as a full DHCPv6
implementation. DHCP is a client-server model protocol, so ISPs can
handle user identification on its network intentionally; also,
authenticated DHCP [13] can be used for secure message exchange.
The expected model for deployment of IPv6 service by ISPs is to
assign a prefix to each customer, which will be used by the customer
gateway to assign a /64 prefix to each network in the customer’s
network. Prefix delegation with DHCP (DHCPv6 PD) has already been
adopted by ISPs for automating the assignment of the customer prefix
to the customer gateway [15]. DNS configuration can be carried in
the same DHCPv6 message exchange used for DHCPv6 to provide that
information efficiently, along with any other configuration
information needed by the customer gateway or customer network. This
service model can be useful to Home or SOHO subscribers. The Home or
SOHO gateway, which is a customer gateway for ISP, can then pass that
RDNSS configuration information to the hosts in the customer network
through DHCP.
5.1.3. Well-known Anycast Addresses Approach
The well-known anycast addresses approach is also a feasible and
simple mechanism for ISP [7]. The use of well-known anycast
addresses avoids some of the security risks in rogue messages sent
through an external protocol such as RA or DHCPv6. The configuration
of hosts for the use of well-known anycast addresses requires no
protocol or manual configuration, but the configuration of routing
for the anycast addresses requires intervention on the part of the
network administrator. Also, the number of special addresses would
be equal to the number of RDNSSes that could be made available to
subscribers.
5.2. Enterprise Network
An enterprise network is defined as a network that has multiple
internal links, one or more router connections to one or more
providers, and is actively managed by a network operations entity
[14]. An enterprise network can get network prefixes from an ISP by
either manual configuration or prefix delegation [15]. In most
cases, because an enterprise network manages its own DNS domains, it
operates its own DNS servers for the domains. These DNS servers
within enterprise networks process recursive DNS name resolution
requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the
enterprise network can be performed as it is in Section 4, in which
three approaches can be used together as follows:
1. An IPv6 host can decide which approach is or may be used in its
subnet with the O flag in RA message [6][28]. As the first
choice in Section 4, well-known anycast addresses can be used as
a last resort when RDNSS information cannot be obtained through
either an RA option or a DHCP option. This case needs IPv6 hosts
to preconfigure the well-known anycast addresses in their DNS
configuration files.
2. When the enterprise prefers the well-known anycast approach to
others, IPv6 hosts should preconfigure the well-known anycast
addresses as it is in the first choice.
3. The last choice, a more convenient and transparent way, does not
need IPv6 hosts to preconfigure the well-known anycast addresses
because the addresses are delivered to IPv6 hosts via either the
RA option or DHCPv6 option as if they were unicast addresses.
This way is most recommended for the sake of the user’s
convenience.
5.3. 3GPP Network
The IPv6 DNS configuration is a missing part of IPv6
autoconfiguration and an important part of the basic IPv6
functionality in the 3GPP User Equipment (UE). The higher-level
description of the 3GPP architecture can be found in [16], and
transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
In the 3GPP architecture, there is a dedicated link between the UE
and the GGSN called the Packet Data Protocol (PDP) Context. This
link is created through the PDP Context activation procedure [19].
There is a separate PDP context type for IPv4 and IPv6 traffic. If a
3GPP UE user is communicating by using IPv6 (i.e., by having an
active IPv6 PDP context), it cannot be assumed that the user
simultaneously has an active IPv4 PDP context, and DNS queries could
be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow
it needs to discover the address of the RDNSS. Before IP-based
services (e.g., web browsing or e-mail) can be used, the IPv6 (and
IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
Section 5.3.1 briefly summarizes currently available mechanisms in
3GPP networks and recommendations. 5.3.2 analyzes the Router
Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6
mechanism, and 5.3.4 analyzes the well-known addresses approach.
Section 5.3.5 summarizes the recommendations.
5.3.1. Currently Available Mechanisms and Recommendations
3GPP has defined a mechanism in which RDNSS addresses can be received
in the PDP context activation (a control plane mechanism). That is
called the Protocol Configuration Options Information Element (PCO-
IE) mechanism [20]. The RDNSS addresses can also be received over
the air (using text messages) or typed in manually in the UE. Note
that the two last mechanisms are not very well scalable. The UE user
most probably does not want to type IPv6 RDNSS addresses manually in
the user’s UE. The use of well-known addresses is briefly discussed
in section 5.3.4.
It is seen that the mechanisms above most probably are not sufficient
for the 3GPP environment. IPv6 is intended to operate in a zero-
configuration manner, no matter what the underlying network
infrastructure is. Typically, the RDNSS address is needed to make an
IPv6 node operational, and the DNS configuration should be as simple
as the address autoconfiguration mechanism. Note that there will be
additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-
specific DNS configuration mechanisms (such as PCO-IE [20]) do not
work for those IP interfaces. In other words, a good IPv6 DNS
configuration mechanism should also work in a multi-access network
environment.
From a 3GPP point of view, the best IPv6 DNS configuration solution
is feasible for a very large number of IPv6-capable UEs (even
hundreds of millions in one operator’s network), is automatic, and
thus requires no user action. It is suggested that a lightweight,
stateless mechanism be standardized for use in all network
environments. The solution could then be used for 3GPP, 3GPP2, and
other access network technologies. Thus, not only is a light,
stateless IPv6 DNS configuration mechanism needed in 3GPP networks,
but also 3GPP networks and UEs would certainly benefit from the new
mechanism.
5.3.2. RA Extension
Router Advertisement extension [6] is a lightweight IPv6 DNS
configuration mechanism that requires minor changes in the 3GPP UE
IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
the 3GPP architecture) IPv6 stack. This solution can be specified in
the IETF (no action is needed in the 3GPP) and taken in use in 3GPP
UEs and GGSNs.
In this solution, an IPv6-capable UE configures DNS information via
an RA message sent by its default router (GGSN); i.e., the RDNSS
option for a recursive DNS server is included in the RA message.
This solution is easily scalable for a very large number of UEs. The
operator can configure the RDNSS addresses in the GGSN as a part of
normal GGSN configuration. The IPv6 RDNSS address is received in the
Router Advertisement, and an extra Round Trip Time (RTT) for asking
RDNSS addresses can be avoided.
When one considers the cons, this mechanism still requires
standardization effort in the IETF, and the end nodes and routers
need to support this mechanism. The equipment software update
should, however, be pretty straightforward, and new IPv6 equipment
could support RA extension already from the beginning.
5.3.3. Stateless DHCPv6
A DHCPv6-based solution needs the implementation of Stateless DHCP
[4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the
operator’s network. A possible configuration is such that the GGSN
works as a DHCP relay.
The pros of a stateless DHCPv6-based solution are:
1. Stateless DHCPv6 is a standardized mechanism.
2. DHCPv6 can be used for receiving configuration information other
than RDNSS addresses; e.g., SIP server addresses.
3. DHCPv6 works in different network environments.
4. When DHCPv6 service is deployed through a single, centralized
server, the RDNSS configuration information can be updated by the
network administrator at a single source.
Some issues with DHCPv6 in 3GPP networks are listed below:
1. DHCPv6 requires an additional server in the network unless the
(Stateless) DHCPv6 functionality is integrated into an existing
router. This means that there might be one additional server to
be maintained.
2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
(3GPP Stateless Address Autoconfiguration is typically used) and
is not automatically implemented in 3GPP IPv6 UEs.
3. Scalability and reliability of DHCPv6 in very large 3GPP networks
(with tens or hundreds of millions of UEs) may be an issue; at
least the redundancy needs to be taken care of. However, if the
DHCPv6 service is integrated into the network elements, such as a
router operating system, scalability and reliability is
comparable with other DNS configuration approaches.
4. It is sub-optimal to utilize the radio resources in 3GPP networks
for DHCPv6 messages if there is a simpler alternative is
available.
* The use of stateless DHCPv6 adds one round-trip delay to the
case in which the UE can start transmitting data right after
the Router Advertisement.
5. If the DNS information (suddenly) changes, Stateless DHCPv6
cannot automatically update the UE; see [21].
5.3.4. Well-known Addresses
Using well-known addresses is also a feasible and light mechanism for
3GPP UEs. Those well-known addresses can be preconfigured in the UE
software and the operator can make the corresponding configuration on
the network side. Thus, this is a very easy mechanism for the UE,
but it requires some configuration work in the network. When using
well-known addresses, UE forwards queries to any of the preconfigured
addresses. In the current proposal [7], IPv6 anycast addresses are
suggested.
Note: An IPv6 DNS configuration proposal, based on the use of well-
known site-local addresses, was developed by the IPv6 Working Group;
it was seen as a feasible mechanism for 3GPP UEs, although no IETF
consensus was reached on this proposal. In the end, the deprecation
of IPv6 site-local addresses made it impossible to standardize a
mechanism that uses site-local addresses as well-known addresses.
However, as of this writing, this mechanism is implemented in some
operating systems and 3GPP UEs as a last resort of IPv6 DNS
configuration.
5.3.5. Recommendations
It is suggested that a lightweight, stateless DNS configuration
mechanism be specified as soon as possible. From a 3GPP UE and
network point of view, the Router Advertisement-based mechanism looks
most promising. The sooner a light, stateless mechanism is
specified, the sooner we can stop using well-known site-local
addresses for IPv6 DNS configuration.
5.4. Unmanaged Network
There are four deployment scenarios of interest in unmanaged networks
[22]:
1. A gateway that does not provide IPv6 at all,
2. A dual-stack gateway connected to a dual-stack ISP,
3. A dual-stack gateway connected to an IPv4-only ISP, and
4. A gateway connected to an IPv6-only ISP.
5.4.1. Case A: Gateway Does Not Provide IPv6 at All
In this case, the gateway does not provide IPv6; the ISP may or may
not provide IPv6. Automatic or Configured tunnels are the
recommended transition mechanisms for this scenario.
The case where dual-stack hosts behind an NAT need access to an IPv6
RDNSS cannot be entirely ruled out. The DNS configuration mechanism
has to work over the tunnel, and the underlying tunneling mechanism
could implement NAT traversal. The tunnel server assumes the role of
a relay (for both DHCP and well-known anycast addresses approaches).
The RA-based mechanism is relatively straightforward in its
operation, assuming the tunnel server is also the IPv6 router
emitting RAs. The well-known anycast addresses approach also seems
simple in operation across the tunnel, but the deployment model using
well-known anycast addresses in a tunneled environment is unclear or
not well understood.
5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP
This is similar to a typical IPv4 home user scenario, where DNS
configuration parameters are obtained using DHCP. The exception is
that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where
the DHCP server is stateful (it maintains the state for clients).
5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP
This is similar to Case B. If a gateway provides IPv6 connectivity
by managing tunnels, then it is also supposed to provide access to an
RDNSS. Like this, the tunnel for IPv6 connectivity originates from
the dual-stack gateway instead of from the host.
5.4.4. Case D: A Gateway Connected to an IPv6-only ISP
This is similar to Case B.
6. Security Considerations
As security requirements depend solely on applications and differ
from application to application, there can be no generic requirement
defined at the IP or application layer for DNS.
However, note that cryptographic security requires configured secret
information and that full autoconfiguration and cryptographic
security are mutually exclusive. People insisting on secure, full
autoconfiguration will get false security, false autoconfiguration,
or both.
In some deployment scenarios [17], where cryptographic security is
required for applications, the secret information for the
cryptographic security is preconfigured, through which application-
specific configuration data, including those for DNS, can be securely
configured. Note that if applications requiring cryptographic
security depend on DNS, the applications also require cryptographic
security to DNS. Therefore, the full autoconfiguration of DNS is not
acceptable.
However, with full autoconfiguration, weaker but still reasonable
security is being widely accepted and will continue to be acceptable.
That is, with full autoconfiguration, which means there is no
cryptographic security for the autoconfiguration, it is already
assumed that the local environment is secure enough that the
information from the local autoconfiguration server has acceptable
security even without cryptographic security. Thus, the
communication between the local DNS client and local DNS server has
acceptable security.
In autoconfiguring recursive servers, DNSSEC may be overkill, because
DNSSEC [23]-[25] needs the configuration and reconfiguration of
clients at root key roll-over [26][27]. Even if additional keys for
secure key roll-over are added at the initial configuration, they are
as vulnerable as the original keys to some forms of attack, such as
social hacking. Another problem of using DNSSEC and
autoconfiguration together is that DNSSEC requires secure time, which
means secure communication with autoconfigured time servers, which
requires configured secret information. Therefore, in order that the
autoconfiguration may be secure, configured secret information is
required.
If DNSSEC [23]-[25] is used and the signatures are verified on the
client host, the misconfiguration of a DNS server may simply be
denial of service. Also, if local routing environment is not
reliable, clients may be directed to a false resolver with the same
IP address as the true one.
6.1. RA Option
The security of RA option for RDNSS is the same as the ND protocol
security [1][6]. The RA option does not add any new vulnerability.
Note that the vulnerability of ND is not worse and is a subset of the
attacks that any node attached to a LAN can do independently of ND.
A malicious node on a LAN can promiscuously receive packets for any
router’s MAC address and send packets with the router’s MAC address
as the source MAC address in the L2 header. As a result, the L2
switches send packets addressed to the router to the malicious node.
Also, this attack can send redirects that tell the hosts to send
their traffic somewhere else. The malicious node can send
unsolicited RA or NA replies, answer RS or NS requests, etc. All of
this can be done independently of implementing ND. Therefore, the RA
option for RDNSS does not add to the vulnerability.
Security issues regarding the ND protocol were discussed by the IETF
SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for
the ND security has been published [12].
6.2. DHCPv6 Option
The DNS Recursive Name Server option may be used by an intruder DHCP
server to cause DHCP clients to send DNS queries to an intruder DNS
recursive name server [5]. The results of these misdirected DNS
queries may be used to spoof DNS names.
To avoid attacks through the DNS Recursive Name Server option, the
DHCP client SHOULD require DHCP authentication (see "Authentication
of DHCP messages" in RFC 3315 [3][13]) before installing a list of
DNS recursive name servers obtained through authenticated DHCP.
6.3. Well-known Anycast Addresses
The well-known anycast addresses approach is not a protocol, thus
there is no need to secure the protocol itself.
However, denial of service attacks on the DNS resolver system might
be easier to achieve as the anycast addresses used are by definition
well known.
7. Contributors
Ralph Droms
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxboro, MA 01719
US
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
US
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
US
EMail: Ted.Lemon@nominum.com
Masataka Ohta
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku
Tokyo 152-8552
Japan
Phone: +81 3 5734 3299
Fax: +81 3 5734 3299
EMail: mohta@necom830.hpcl.titech.ac.jp
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-Gu
Suwon, Gyeonggi-Do 443-742
Korea
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Suresh Satapati
Cisco Systems, Inc.
San Jose, CA 95134