One document matched: draft-ietf-dnsop-ipv6-dns-configuration-00.txt
DNS Operations WG
Internet-Draft J. Jeong
R. Droms
R. Hinden
T. Lemon
M. Ohta
S. Park
S. Satapati
J. Wiljakka
Expires: November 2004 28 May 2004
IPv6 Host Configuration of DNS Server Information Approaches
draft-ietf-dnsop-ipv6-dns-configuration-00.txt
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC3668 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes three approaches for IPv6 DNS server address
configuration. It details the operational attributes of three
solutions: RA option, DHCPv6 option, and Well-known anycast addresses
Jeong, et al. Expires - November 2004 [Page 1]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
for Recursive DNS Servers. Additionally, it suggests four deployment
scenarios considering multi-solution resolution. Therefore, this
document will give the audience a guideline of IPv6 DNS configuration
to select approaches suitable for their host DNS configuration.
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................3
3. IPv6 DNS Configuration Approaches.............................3
3.1 RA Option................................................3
3.1.1 Advantages.............................................4
3.1.2 Disadvantages..........................................5
3.1.3 Observations...........................................5
3.2 DHCPv6 Option............................................5
3.2.1 Advantages.............................................7
3.2.2 Disadvantages..........................................7
3.2.3 Observations...........................................8
3.3 Well-known Anycast Addresses.............................8
4. Interworking among IPv6 DNS Configuration Approaches..........9
5. Deployment Scenarios.........................................10
5.1 ISP Network.............................................10
5.1.1 RA Option Approach....................................10
5.1.2 DHCPv6 Option Approach................................11
5.1.3 Well-Known Addresses Approach.........................11
5.1.4 ISP Network for Home or SOHO Subscribers..............11
5.2 Enterprise Network......................................12
5.2.1 DNS Configuration in Multi-level Network Topology.....12
5.3 3GPP Network............................................13
5.3.1 Currently Available Mechanisms and Recommendations....13
5.3.2 RA Extension..........................................14
5.3.3 Stateless DHCPv6......................................15
5.3.4 Well-known Addresses..................................15
5.3.5 Recommendations.......................................16
5.4 Unmanaged Network.......................................16
5.4.1 Case A: Gateway does not provide IPv6 at all..........16
5.4.2 Case B: A dual-stack gateway connected to a dual-stack
ISP...................................................17
5.4.3 Case C: A dual-stack gateway connected to an IPv4-only
ISP...................................................17
5.4.4 Case D: A gateway connected to an IPv6-only ISP.......17
6. Security Considerations......................................17
7. Acknowledgements.............................................18
8. Normative References.........................................18
9. Informative References.......................................18
10. Authors' Addresses..........................................19
Intellectual Property Statement.................................21
Full Copyright Statement........................................21
Jeong, et al. Expires - November 2004 [Page 2]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
1. Introduction
IPv6 stateless address autoconfiguration provides a way to
autoconfigure either fixed or mobile nodes with one or more IPv6
addresses, default routes and some other parameters [3][4]. To
support access to additional services in the Internet that are
identified by a DNS name, such as a web server, the configuration of
at least one recursive DNS server for DNS name resolution is also
needed.
This document describes three approaches of DNS server address
configuration for IPv6 host: (a) RA Option [5], (b) DHCPv6 Option
[6]-[8], and (c) Well-Known Anycast Addresses for Recursive DNS
Servers [9]. Also, it suggests applicable scenarios for four kinds
of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
network, and (d) Unmanaged network.
Therefore, this document will help the audience select approaches
suitable for IPv6 host configuration of recursive DNS server.
2. Terminology
This memo uses the terminology described in [3]-[9]. In addition, a
new term is defined below:
Recursive DNS Server (RDNSS) A Recursive DNS Server is a name
server that offers the recursive
service of DNS name resolution.
3. IPv6 DNS Configuration Approaches
In this section, the operational attributes of three solutions are
described in detail.
3.1 RA Option
RA approach is to define a new Neighbor Discovery (ND) option called
RDNSS option that contains a recursive DNS server address. Existing
ND transport mechanisms (i.e., advertisements and solicitations)
mechanisms are used. This works in the same way that nodes learn
about routers and prefixes, etc. An IPv6 host can configure the IPv6
addresses of one or more recursive DNS servers via RA message sent
periodically by router or solicited by a Router Solicitation (RS)
[5].
This approach has an issue that the DNS information needs to be
configured in the routers doing the advertisements. The configura-
tion of DNS server address can be performed manually by operator or
automatically DHCPv6 client running on the router. When advertising
Jeong, et al. Expires - November 2004 [Page 3]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
more than one RDNSS options, an RA message includes as many RDNSS
options as DNS servers. Through ND protocol and RDNSS option along
with prefix information option, an IPv6 host can perform its network
configuration of its IPv6 address and recursive DNS server
simultaneously [3][4]. The RA option for recursive DNS server can be
used on any network that supports the use of ND. RA approach is
light-weight especially in wireless environment where RA message is
used for IPv6 address autoconfiguration, such as cellular networks.
The RA approach is useful in environments where the addresses of the
recursive DNS server(s) is changing because the RA option includes a
lifetime field. This can be configured to a value that will require
the client to time out the entry and switch over to another recursive
server address [5].
The preference value of DNS server, included in RDNSS option, allows
IPv6 hosts to select primary DNS server among several servers; this
can be used for load balancing of DNS servers [5].
3.1.1 Advantages
The RA Option for RDNSS has a number of advantages. These include:
1) The RA option is a simple extension of existing ND/Autoconfig
mechanisms [3][4]. No new protocol mechanisms are needed and
extending an ND implementation to support this option should be very
simple.
2) This approach, like ND, works well on a variety of link types
including point-to-point links, point-to-multipoint, and multi-point
(i.e., LANs), etc. RFC2461 [3] states that there may be some link
type on which ND is not possible; on such a link, some other
mechanism will be needed for DNS configuration.
3) All of the information a host needs to run basic internet
applications such as email, the web, ftp, etc., can be performed with
the addition of this option to ND and address autoconfiguration.
The use of a single mechanism is more reliable and easier to
provide than when the recursive DNS server information is learned
via another protocol mechanism. Debugging problems when multiple
protocol mechanisms are being used is harder and much more complex.
4) This mechanism works over a broad range of scenarios and leverages
IPv6 ND. It works well on links that are high performance (e.g.,
LANs) and low performance (e.g., wireless LANs and cellular
networks).
In the latter case, combining the recursive DNS server information
with the other information in the RA, the host can learn all of the
information needed to use most Internet applications such as the web
Jeong, et al. Expires - November 2004 [Page 4]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
in a single packet. This not only saves bandwidth where this is an
issue, but also minimizes the delay to learn the recursive DNS server
information.
5) The RA approach could be used as a model for other similar types
of configuration information. New RA options for other server
addresses that are common to all clients on a subnet would be easy to
define. This includes things like NTP servers, SIP servers, etc.
3.1.2 Disadvantages
ND is mostly implemented in kernel part of operating system.
Therefore, if ND supports the configuration of some additional
services, such as DNS, NTP and SIP servers, ND should be extended in
kernel part and need kernel compilation. DHCPv6, however, has more
flexibility for extension of service discovery because it is an
application layer protocol.
3.1.3 Observations
The proposed RDNSS RA option along with IPv6 ND and Auto-
Configuration allows a host to obtain all of the information it needs
to access basic internet services like the web, email, ftp, etc.
This is preferable in environments where hosts use RAs to auto-
configure their addresses and all hosts on the subnet share the same
router and server addresses. It is preferable because the
configuration information can be obtained from a single mechanism, it
does not add additional delay, and it uses a minimum of bandwidth.
Environments like this include homes, public WLAN hot spots, public
cellular networks, and enterprise environments where no per host
configuration is needed.
DHCPv6 is preferable where it is being used for address configuration
and if there is a need for host specific configuration. Environments
like this are most likely enterprise environments where the local
administration chooses to have per host configuration control.
3.2 DHCPv6 Option
DHCPv6 [6] includes the "DNS Recursive Name Server" option, through
which a host can obtain a list of IP addresses of recursive DNS
servers [8]. The DNS Recursive Name Server option carries a list of
IPv6 address of RDNSSes to which the host may send DNS queries. The
DNS servers are listed in the order of preference for use by the DNS
resolver on the host.
The DNS Recursive Name Server option can be carried in any DHCPv6
Reply message, in response to either a Request or an Information-
Jeong, et al. Expires - November 2004 [Page 5]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
request message. Thus, the DNS Recursive Name Server option can be
used either when DHCPv6 is used for address assignment, or when
DHCPv6 is used only for other configuration information as stateless
DHCPv6 [7].
Stateless DHCPv6 can be deployed either using DHCPv6 servers running
on general-purpose computers, or on router hardware. Several router
vendors currently implement stateless DHCPv6 servers. Deploying
stateless DHCPv6 in routers has the advantage that no special
hardware is required, and should work well for networks where DHCPv6
is needed for very straightforward configuration of network devices.
However, routers can also act as DHCPv6 relay agents. In this case,
the DHCPv6 server need not be on the router - it can be on a general
purpose computer. This has the potential to give the operator of the
DHCPv6 server more flexibility in how the DHCPv6 server responds to
individual clients - clients can easily be given different
configuration information based on their identity, or for any other
reason. Nothing precludes adding this flexibility to a router, but
generally in current practice, DHCP servers running on general-
purpose hosts tend to have more configuration options than those that
are embedded in routers.
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
clients. To do this, the DHCPv6 server sends a Reconfigure message
to the client. The client validates the Reconfigure message, and
then contacts the DHCPv6 server to obtain updated configuration
information. Using this mechanism, it is currently possible to
propagate new configuration information to DHCPv6 clients as this
information changes.
The dhc WG is currently studying an additional mechanism through
which configuration information, including the list of RDNSSes, can
be updated. The Lifetime Option for DHCPv6 [10], assigns a lifetime
to configuration information obtained through DHCPv6. At the
expiration of the lifetime, the host contacts the DHCPv6 server to
obtain updated configuration information, including the list of
RDNSSes. This lifetime gives the network administrator another
mechanism to configure hosts with new RDNSSes by controlling the time
at which the host refreshes the list.
The dhc WG has also discussed the possibility of defining an
extension to DHCPv6 that would allow the use of multicast to provide
configuration information to multiple hosts with a single DHCPv6
message. Because of the lack of deployment experience, the WG has
deferred consideration of multicast DHCPv6 configuration at this
time.
Experience with DHCPv4 has not identified a requirement for multicast
message delivery, even in large service provider networks with tens
Jeong, et al. Expires - November 2004 [Page 6]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
of thousands of hosts that may initiate a DHCPv4 message exchange
simultaneously.
3.2.1 Advantages
The DHCPv6 option for RDNSS has a number of advantages. These
include:
1) DHCPv6 currently provides a general mechanism for conveying
network configuration information to clients. So configuring DHCPv6
servers allows the network administrator to configure recursive DNS
servers along with the addresses of other network services, as well
as location-specific information like time zones.
2) As a consequence, when the network administrator goes to configure
DHCPv6, all the configuration information can be managed through a
single service, typically with a single user interface and a single
configuration database.
3) DHCPv6 allows for the configuration of a host with information
specific to that host, so that hosts on the same link can be
configured with different DNS recursive name servers as well as
other configuration information. This capability is important in
some network deployments such as service provider networks or WiFi
hotspots.
4) A mechanism exists for extending DHCPv6 to support the
transmission of additional configuration that has not yet been
anticipated.
5) Hosts in some environments are likely to need DHCPv6 for other
configuration information.
6) The specification for configuration of DNS recursive name servers
through DHCPv6 is available as an RFC.
7) Interoperability among independent implementations demonstrated at
TAHI and Connectathon.
3.2.2 Disadvantages
The DHCPv6 option for RDNSS has a few disadvantages. These include:
1) Update currently requires message from server (however, see [10]).
2) Because DNS information is not contained in RA message, the host
must receive two messages from the router, and must transmit at
least one message to the router. On networks where bandwidth is at a
Jeong, et al. Expires - November 2004 [Page 7]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
premium, this is a disadvantage, although on most networks it is not
a practical concern.
3) Increased latency for initial configuration - in addition to
waiting for an RA message, the client must now exchange packets
with a DHCPv6 server; even if it is locally installed on a router,
this will slightly extend the time required to configure the client.
For clients that are moving rapidly from one network to another, this
will be a disadvantage.
3.2.3 Observations
We are aware of some applications where it would be preferable to put
the recursive DNS configuration information into an RA packet; for
example, on a cell phone network, where bandwidth is at a premium and
extremely low latency is desired. The final DNS configuration draft
should be written so as to allow these special applications to be
handled using DNS information in the RA packet.
However, in the general case, on general-purpose networks, stateless
DHCPv6 provides significant advantages and no significant
disadvantages. Even in the case where bandwidth is at a premium and
low latency is desired, if hosts require other configuration
information in addition to a list of DNS recursive name servers or if
hosts must be configured selectively, those hosts will use DHCPv6 and
the use of the DHCPv6 DNS recursive name server option will be
advantageous.
3.3 Well-known Anycast Addresses
The approach with well-known anycast addresses is to set well-known
anycast addresses in clients' resolver configuration files from the
beginning, say, as factory default. Thus, there is no transport
mechanism and no packet format. There is no delay to get response
and no further delay by packet losses [9].
If other approaches are used in addition, the well-known anycast
addresses should also be set in RA or DHCP configuration files from
the beginning, say, as factory default to reduce configuration effort
of users.
An anycast address is an address shared by multiple servers (in this
case, servers are recursive resolvers). Request from a client to the
anycast address is routed to a server selected by the routing system.
The selection can be simply based on routing metric or policy based
one. However, it is a bad idea to mandate "site" boundary on anycast
addresses, because, most users just do not have their own servers and
want to access their ISPs' across their site boundaries. Larger sites
Jeong, et al. Expires - November 2004 [Page 8]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
may also depend on their ISPs or may have their own recursive
resolvers within "site" boundaries.
DNS clients have redundancy by having multiple resolvers that there
should be multiple well-known anycast addresses configured on
clients.
There is no point to have multiple servers sharing an anycast address
on a single link.
Small ISPs will operate one recursive resolver at each anycast
address which is shared by all the subscribers. Large ISPs may
operate multiple recursive resolvers at each anycast address to
distribute and reduce load, in which case, boundary between servers
may be fixed (redundancy is still provided by multiple addresses) or
change dynamically. DNS packets with the well-known anycast
addresses are not expected to cross ISP boundaries, as ISPs are
expected to be able to take care of themselves.
Well-known anycast addresses can be combined with cryptographic
security such as TSIG or DNSSEC. However, there is no point to avoid
manual configuration of DNS when secret information (such as a shared
secret key or a public key of root zone) for the cryptographic
security must manually be configured (and updated periodically).
4. Interworking among IPv6 DNS Configuration Approaches
Three approaches can work together for IPv6 host configuration of DNS
server.
For ordering between RA and DHCP approaches, O (Other stateful
configuration) flag in RA message can be used [5]. If no RDNSS
option is included and O flag is set on in RA message, an IPv6 Host
may perform DNS configuration through DHCPv6 [6]-[8].
The well-known anycast addresses approach fully interworks with the
other approaches. That is, the other approaches can remove
configuration effort on servers by using the well-known addresses as
the default configuration. Moreover, clients preconfigured with
well-known anycast addresses can be further configured to use other
approaches to override the well-known addresses, if configuration
information from other approaches are available. That is, all the
clients should have the well-known anycast addresses preconfigured,
in the case where there is no other mechanisms available. In order
to fly anycast approach with the other solutions, there are three
options.
The first option is that well-known addresses are used as last
resort,
when an IPv6 host cannot get DNS server information through RA and
DHCP.
Jeong, et al. Expires - November 2004 [Page 9]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
The second is that an IPv6 host can configure well-known addresses as
the most preferable in its configuration file.
The last is that the well-known anycast addresses can be set in RA or
DHCP configuration from the beginning, say, as factory default to
reduce configuration effort of users. According to either RA or DHCP
mechanism, the well-known addresses can be gotten by IPv6 host.
5. Deployment Scenarios
Regarding DNS configuration on the IPv6 host, several mechanisms have
being considered in the DNSOP Working Group such as Router
Advertisement extension, DHCPv6 and well-known preconfigured anycast
addresses as of today, and this document is a final result from the
long thread.
Note: in the applicable scenarios, authors do not implicitly push any
specific approaches into the restricted environments. No enforcement
is in this scenario and all mentioned scenarios are probable. The
main objective of this work is to provide a useful guideline as
Informational RFC.
5.1 ISP Network
From the ISP aspect, the IPv6 PE (Provider Edge equipment)
configuration is very difficult task because each host connects
multiple CPE (Customer Premises Equipment) components to the backbone
network infrastructure and even more difficult because configuration
must be done remotely [11]. Three approaches for DNS configuration
will benefit ISP network.
5.1.1 RA Option Approach
RA extension for recursive DNS server can be used to allow a host to
get its recursive DNS server as well as IPv6 prefix at the same time
through a new DNS option [5] within RA message when the host is
attached to a new subnet. For easy configuration on the ISP, DNS
information, unsolicited RA message including a new DNS option can be
delegated to its subnet periodically. 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 that RA without the overhead of an
additional message exchange.
This approach is so valuable in the mobile scenario which must
receive at least an RA message for detecting a new network than
others although administrator must configure DNS information on the
Jeong, et al. Expires - November 2004 [Page 10]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
routers. Secure ND [12] can provide extended security when using RA
message.
5.1.2 DHCPv6 Option Approach
DHCPv6 can be used for RDNSS configuration through the use of the
Recursive DNS Server option, and can provide other configuration
information in the same message with RDNSS configuration [6]-[8].
Particularly, most ISPs are widely using DHCPv4 to allocate dynamic
IPv4 addresses to their customers in the current Internet, so that
DHCPv6 can be may applied for the current Internet in the same way.
DHCPv6 DNS option is already in place for DHCPv6 as RFC 3646 [8] and
moreover DHCPv6-lite or stateless DHCP [7] is nowhere as complex as a
full DHCPv6 implementation. DHCP is a client-server model protocol,
so ISP can handle user identification on its network intentionally,
and also authenticated DHCP [13] can be used for secure message
exchange.
Major applicable environment is probably home network because most
DSL gateways have a DHCP server now, and many of them have some sort
of DNS cache or relay. For this operation, all users and ISP
delegating equipments need to have DHCP function.
5.1.3 Well-Known Addresses Approach
Well-known anycast addresses approach is also a feasible and simple
mechanism for ISP [9]. The use of well-known anycast addresses
avoids some of the security risks in rogue messages sent through an
external protocol like 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 DNS servers that could be made available to
subscribers.
5.1.4 ISP Network for Home or SOHO Subscribers
One usual model for an ISP customer network is to have a Home or SOHO
gateway at the edge of the customer network, which is connected to
the ISP edge device. DHCPv6 prefix delegation can be used to assign
and communicate the customer prefixes from the ISP device to the Home
or SOHO gateway.
Because most home or SOHO subscribers will not bother to have their
own DNS servers and will not configure any information, not even that
for cryptographic security, the information about RDNSSes provided by
the ISP can be communicated to the Home or SOHO gateway through the
Jeong, et al. Expires - November 2004 [Page 11]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
prefix delegation message exchange. The Home or SOHO gateway can
then pass that RDNSS configuration information to the hosts in the
customer network.
Home or SOHO subscribers with PPP connectivity will not configure any
information beyond that required for PPP. They just rely on their
ISPs and the connections to the ISPs are secure. Therefore, such
most subscribers can just rely on local DNS servers provided by their
ISPs without any cryptographic security. Subscribers are still free
to have their own mechanism for better security with its own
configuration information.
5.2 Enterprise Network
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 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
network process recursive DNS name resolution requests of IPv6 hosts.
DNS server configuration in enterprise network can be performed like
in Section 4, in which three approaches can be used together.
IPv6 host can decide which approach is or may be used in its subnet
with O flag in RA message. For the first option in Section 4, well-
known anycast addresses are used as a last resort when O flag in RA
message is set off and RDNSS RA option is not included. The option
needs IPv6 hosts to preconfigure the well-known anycast addresses in
their DNS configuration storage, e.g., /etc/resolv.conf in UNIX.
When the enterprise prefers well-known anycast approach to the
others,
IPv6 hosts should preconfigure the well-known anycast addresses like
in the first option.
The last option, 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 through either RA option or
DHCPv6 option as if they were unicast addresses. This way is most
recommended for the sake of user's convenience.
5.2.1 DNS Configuration in Multi-level Network Topology
The enterprise will have multi-level network topology. A network
administrator can easily configure DNS server in each router if (s)he
uses DHCPv6 Client/Server and DHCPv6 DNS Option [6]-[8]. (S)he
manually needs to configure DNS information only in top-level
Jeong, et al. Expires - November 2004 [Page 12]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
router(s). The rest of routers below can automatically configure DNS
information through DHCPv6. In the case where ND is used for address
autoconfiguration, the RA Option for recursive DNS server can be used
for IPv6 host configuration of DNS server in each network level. For
redundancy and load sharing, well-known anycast addresses can be used
by IPv6 hosts through RDNSS RA option. Therefore, this model for DNS
configuration is convenient and efficient to both network
administrator and users.
5.3 3GPP Network
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). 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 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 using IPv6 (having an active IPv6 PDP
context), it can not be assumed that (s)he has simultaneously active
IPv4 PDP context, and DNS queries could be done using IPv4. A 3GPP
UE can thus be an IPv6 node, and it needs to somehow discover the
address of the DNS server. Before IP-based services (e.g., web
browsing or e-mail) can be used, the IPv6 (and IPv4) DNS server
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 finally summarizes the recommendations.
5.3.1 Currently Available Mechanisms and Recommendations
3GPP has defined a mechanism, in which DNS server 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]. It is also possible to use
Stateless DHCPv6 for receiving DNS server addresses (described in
section 5.3.3) [7][8]. The DNS server 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 DNS
server addresses manually in his/her UE. The use of well-known
addresses is briefly discussed in section 5.3.4.
Jeong, et al. Expires - November 2004 [Page 13]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
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 DNS server address is needed to
make an IPv6 node operational - and the DNS configuration should be
as simple as the address autoconfiguration mechanism. It must also
be noted that there will be additional IP interfaces in some near
future 3GPP UEs, e.g., Wireless LAN (WLAN), and 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 3GPP point of view, the best IPv6 DNS configuration solution is
feasible for a very large number of IPv6-capable UEs (can be even
hundreds of millions in one operator's network), is automatic and
thus requires no user action. It is suggested to standardize a
lightweight, stateless mechanism that works in all network
environments. The solution could then be used for 3GPP, 3GPP2, WLAN
and other access network technologies. A light, stateless IPv6 DNS
configuration mechanism is thus not needed in 3GPP networks only, but
also 3GPP networks and UEs would certainly benefit from the new
mechanism.
5.3.2 RA Extension
Router Advertisement extension [5] is a lightweight IPv6 DNS
configuration mechanism that requires minor changes in 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 needed in the 3GPP) and taken in use in 3GPP
UEs and GGSNs.
In this solution, an IPv6-capable UE configures DNS information
via RA message sent by its default router (GGSN), i.e., RDNSS option
for 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 DNS addresses in the GGSN as a part of
normal GGSN configuration. The IPv6 DNS server address is received
in the Router Advertisement, and an extra Round Trip Time (RTT) for
asking DNS server addresses can be avoided.
If thinking about 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.
Jeong, et al. Expires - November 2004 [Page 14]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
5.3.3 Stateless DHCPv6
DHCPv6-based solution needs the implementation of Stateless DHCP
[7] and DHCPv6 DNS options [8] 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.
Pros for Stateless DHCPv6-based solution are
1) Stateless DHCPv6 is a standardized mechanism.
2) DHCPv6 can be used for receiving other configuration information
than DNS server addresses, e.g., SIP server addresses.
3) DHCPv6 works in different network environments.
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 already, and it is one box more to be maintained.
2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing (3GPP
Stateless Address Autoconfiguration is typically used), and 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 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 available.
a) 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 can
not automatically update the UE, see [21].
5.3.4 Well-known Addresses
Using well-known addresses is also a feasible and a light mechanism
for 3GPP UEs. Those well-known addresses can be preconfigured in
the UE software and the operator makes the corresponding
configuration on the network side. So this is a very easy mechanism
for the UE, but requires some configuration work in the network.
Jeong, et al. Expires - November 2004 [Page 15]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
When using well-known addresses, UE forwards queries to any of the
preconfigured addresses. In the current proposal [9], IPv6 anycast
addresses are suggested.
IPv6 DNS configuration proposal based on the use of well-known site-
local addresses developed in the IPv6 Working Group was seen as a
feasible mechanism for 3GPP UEs, but opposition by some people in
the IETF and finally deprecating IPv6 site-local addresses made it
impossible to standardize it. Note that this mechanism is
implemented in some existing operating systems today (also in some
3GPP UEs) as a last resort IPv6 DNS configuration mechanism.
5.3.5 Recommendations
It is suggested that a lightweight, stateless DNS configuration
mechanism is specified as soon as possible. From 3GPP UE's and
networks' point of view, Router Advertisement based mechanism looks
most promising. The sooner a light, stateless mechanism is
specified, the sooner we can get rid of using well-known site-local
addresses for IPv6 DNS configuration.
5.4 Unmanaged Network
There are 4 deployment scenarios of interest in unmanaged networks
[22]:
1) A gateway which 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 a NAT, that need access to an
IPv6 Recursive DNS Server, cannot be entirely ruled out. The DNS
configuration mechanism has to work over the tunnel, and the
underlying tunneling mechanism could be implementing NAT traversal.
The tunnel server assumes the role of a relay (both for DHCP and
Well-known addresses approaches). However, the deployment model of
Stateless DHCP Server in a tunneled environment is not well
understood or may not be justified.
Jeong, et al. Expires - November 2004 [Page 16]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
RA-based mechanism is relatively straightforward in its operation,
assuming the tunnel server is also the IPv6 router emitting RAs.
Well-known address approach seems also simple in operation across the
tunnel, but the deployment model using Well-known 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
config parameters are obtained using DHCP. Except that Stateless
DHCPv6 is used, as opposed to the IPv4 scenario where the DHCP server
is stateful (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 A, except that the tunnel originates from the
dual-stack gateway instead of 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 are
different application by application, there can be no generic
requirement defined at higher IP or lower application layer of DNS.
However, it should be noted that cryptographic security requires
configured secret information 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 scenario [17], where cryptographic security is
required for applications, secret information for the cryptographic
security is preconfigured through which application specific
configuration data, including those for DNS, can be securely
configured. It should be noted that if applications requiring
cryptographic security depends 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
Jeong, et al. Expires - November 2004 [Page 17]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
assumed that local environment is secure enough that information from
local autoconfiguration server has acceptable security even without
cryptographic security. Thus, communication between a local DNS
client and a local DNS server has the acceptable security.
For security considerations of each approach, refer to the
corresponding drafts [5]-[9].
7. Acknowledgements
This draft has greatly benefited from inputs by David Meyer and Rob
Austein. The authors appreciate their contribution.
8. Normative References
[1] S. Bradner, "Intellectual Property Rights in IETF Technology",
RFC 3668, February 2004.
[2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February
2004.
[3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP
Version 6 (IPv6)", RFC 2461, December 1998.
[4] S. Thomson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[5] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS
Discovery based on Router Advertisement", draft-jeong-dnsop-
ipv6-dns-discovery-01.txt, February 2004.
[6] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[7] R. Droms, "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004.
[8] R. Droms et al., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
2003.
[9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta-
preconfigured-dns-01.txt, February 2004.
9. Informative References
[10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft-
ietf-dhc-lifetime-00.txt, March 2004.
Jeong, et al. Expires - November 2004 [Page 18]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
[11] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-
02.txt, April 2004.
[12] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-ietf-
send-ndopt-05.txt, April 2004.
[13] R. Droms and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
[14] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft-
ietf-v6ops-ent-scenarios-01.txt, February 2004.
[15] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December
2003.
[16] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP
Standards", RFC 3314, September 2002.
[17] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", RFC
3574, August 2003.
[18] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP
Networks", draft-ietf- v6ops-3gpp-analysis-09.txt, March 2004.
[19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
Service description; Stage 2 (Release 5)", December 2002.
[20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
specification; Core network protocols; Stage 3 (Release 5)",
June 2003.
[21] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering
Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-
dhcpv6-renumbering-00.txt, March 2004.
[22] C. Huitema et al., "Unmanaged Networks IPv6 Transition
Scenarios", RFC 3750, April 2004.
10. Authors' Addresses
Jaehoon Paul Jeong, Editor
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea
Jeong, et al. Expires - November 2004 [Page 19]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
Phone: +82 42 860 1664
Fax: +82 42 861 5404
EMail: paul@etri.re.kr
Ralph Droms
Cisco Systems
1414 Massachusetts Ave.
Boxboro, MA 01719
USA
Phone: +1 978 936 1674
EMail: rdroms@cisco.com
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Ted Lemon
Nominum, Inc.
950 Charter Street
Redwood City, CA 94043
USA
EMail: Ted.Lemon@nominum.com
Masataka Ohta
Graduate School of Information Science and Engineering
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, Paldal-Gu, Suwon
Gyeonggi-Do
Korea
Jeong, et al. Expires - November 2004 [Page 20]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Suresh Satapati
Cisco Systems, Inc.
San Jose, CA 95134
USA
EMail: satapati@cisco.com
Juha Wiljakka
Nokia
Visiokatu 3
FIN-33720 TAMPERE
Finland
Phone: +358 7180 48372
EMail: juha.wiljakka@nokia.com
Intellectual Property Statement
The following intellectual property notice is copied from RFC3668
[1],
Section 5.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Statement
Jeong, et al. Expires - November 2004 [Page 21]
Internet-Draft IPv6 Host Configuration of DNS Server May 2004
The following copyright notice is copied from RFC3667 [2], Section
5.4. It describes the applicable copyright for this document.
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Jeong, et al. Expires - November 2004 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 18:11:51 |