-
DNS Operations WG
Internet-Draft J. Jeong (ed.)
ETRI/University of Minnesota
-Expires: March 2005 28 September 2004
+Expires: August 2005 19 February 2005
IPv6 Host Configuration of DNS Server Information Approaches
- draft-ietf-dnsop-ipv6-dns-configuration-04.txt
+ draft-ietf-dnsop-ipv6-dns-configuration-05.txt
Status of this Memo
- By submitting this Internet-Draft, I certify that any applicable
- patent or other IPR claims of which I am aware have been disclosed,
- and any of which we become aware will be disclosed, in accordance
- with RFC3668.
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
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.
-
+ 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
progress."
The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
+ http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
+ http://www.ietf.org/shadow.html"
- This Internet-Draft will expire on March 27, 2005.
+ This Internet-Draft will expire on August 19, 2005.
Copyright Notice
- Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes three approaches for IPv6 recursive DNS
server address configuration. It details the operational
- attributes of three solutions: RA option, DHCPv6 option, and Well-
- known anycast addresses for recursive DNS servers. Additionally,
- it suggests four deployment scenarios considering multi-solution
- resolution. Therefore, this document will give the audience a
+ attributes of three solutions: RA option, DHCPv6 option, and
+ Well-known anycast addresses for recursive DNS servers.
-Jeong, et al. Expires - March 2005 [Page 1]
+Jeong, et al. Expires - August 2005 [Page 1]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- guideline for IPv6 DNS configuration to select approaches suitable
- for their host DNS configuration.
+ Additionally, it suggests four deployment scenarios considering
+ multi-solution resolution. Therefore, this document will give the
+ audience a guideline for IPv6 DNS configuration to select the
+ 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........................................6
- 3.2. DHCPv6 Option..............................................6
- 3.2.1. Advantages..........................................7
- 3.2.2. Disadvantages.......................................8
- 3.2.3. Observations........................................9
- 3.3. Well-known Anycast Addresses...............................9
- 3.3.1. Advantages.........................................10
- 3.3.2. Disadvantages......................................10
- 3.3.3. Observations.......................................10
- 4. Interworking among IPv6 DNS Configuration Approaches...........11
- 5. Deployment Scenarios...........................................12
- 5.1. ISP Network...............................................12
- 5.1.1. RA Option Approach.................................12
- 5.1.2. DHCPv6 Option Approach.............................13
- 5.1.3. Well-known Addresses Approach......................13
- 5.2. Enterprise Network........................................14
- 5.3. 3GPP Network..............................................14
- 5.3.1. Currently Available Mechanisms and Recommendations.15
- 5.3.2. RA Extension.......................................16
- 5.3.3. Stateless DHCPv6...................................16
- 5.3.4. Well-known Addresses...............................17
- 5.3.5. Recommendations....................................17
- 5.4. Unmanaged Network.........................................18
- 5.4.1. Case A: Gateway does not provide IPv6 at all.......18
- 5.4.2. Case B: A dual-stack gateway connected to a
- dual-stack ISP.....................................18
- 5.4.3. Case C: A dual-stack gateway connected to an
- IPv4-only ISP......................................19
- 5.4.4. Case D: A gateway connected to an IPv6-only ISP....19
- 6. Security Considerations........................................19
- 7. Acknowledgements...............................................19
- 8. Normative References...........................................20
- 9. Informative References.........................................20
- 10. Appendix A - Link-layer Multicast Acknowledgements with RA
- Option........................................................21
- 11. Authors' Addresses............................................22
- 12. Intellectual Property Statement...............................23
-
-
-Jeong, et al. Expires - March 2005 [Page 2]
+ 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.........................................6
+ 3.2. DHCPv6 Option..............................................6
+ 3.2.1. Advantages...........................................8
+ 3.2.2. Disadvantages........................................8
+ 3.2.3. Observations.........................................9
+ 3.3. Well-known Anycast Addresses...............................9
+ 3.3.1. Advantages..........................................10
+ 3.3.2. Disadvantages.......................................10
+ 3.3.3. Observations........................................11
+ 4. Interworking among IPv6 DNS Configuration Approaches..........11
+ 5. Deployment Scenarios..........................................12
+ 5.1. ISP Network...............................................13
+ 5.1.1. RA Option Approach..................................13
+ 5.1.2. DHCPv6 Option Approach..............................13
+ 5.1.3. Well-known Addresses Approach.......................14
+ 5.2. Enterprise Network........................................14
+ 5.3. 3GPP Network..............................................15
+ 5.3.1. Currently Available Mechanisms and Recommendations..15
+ 5.3.2. RA Extension........................................16
+ 5.3.3. Stateless DHCPv6....................................17
+ 5.3.4. Well-known Addresses................................18
+ 5.3.5. Recommendations.....................................18
+ 5.4. Unmanaged Network.........................................18
+ 5.4.1. Case A: Gateway does not provide IPv6 at all........18
+ 5.4.2. Case B: A dual-stack gateway connected to a dual-stack
+ ISP.................................................19
+ 5.4.3. Case C: A dual-stack gateway connected to an IPv4-only
+ ISP.................................................19
+ 5.4.4. Case D: A gateway connected to an IPv6-only ISP.....19
+ 6. Security Considerations.......................................19
+ 7. Acknowledgements..............................................20
+ 8. Normative References..........................................20
+ 9. Informative References........................................21
+ 10. Appendix A - Link-layer Multicast Acknowledgements with RA
+ Option.......................................................23
+
+
+Jeong, et al. Expires - August 2005 [Page 2]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- Full Copyright Statement..........................................24
- Acknowledgement...................................................24
+ 11. Authors' Addresses...........................................23
+ 12. Intellectual Property Statement..............................25
+ 13. Full Copyright Statement.....................................25
+ Acknowledgement..................................................26
1. Introduction
- Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
- Autoconfiguration provide ways to configure 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 is
- also needed for DNS name resolution.
+ Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+ Autoconfiguration provide the ways to configure either fixed or
+ mobile nodes with one or more IPv6 addresses, default routes and
+ some other parameters [3][4]. To support the 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 is also needed for DNS name resolution.
This document describes three approaches of recursive DNS server
address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
option [5]-[7], 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.
+ DNS servers [9]. Also, it suggests the applicable scenarios for
+ four kinds of networks: (a) ISP network, (b) Enterprise network,
+ (c) 3GPP network, and (d) Unmanaged network.
This document is just an analysis of each possible approach, and
does not make any recommendation on particular one or on a
adopted at all as a result of further discussion.
Therefore, the objective of this document is to help the audience
- select approaches suitable for IPv6 host configuration of recursive
- DNS server.
+ select the approaches suitable for IPv6 host configuration of
+ recursive DNS server.
2. Terminology
3.1. RA Option
- RA approach is to define a new ND option called RDNSS option that
- contains a recursive DNS server address. Existing ND transport
- mechanisms (i.e., advertisements and solicitations) are used. This
+
-Jeong, et al. Expires - March 2005 [Page 3]
+Jeong, et al. Expires - August 2005 [Page 3]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- works in the same way that nodes learn about routers and prefixes.
+ RA approach is to define a new ND option called RDNSS option that
+ contains a recursive DNS server address. Existing ND transport
+ mechanisms (i.e., advertisements and solicitations) are used. This
+ works in the same way that nodes learn about routers and prefixes.
An IPv6 host can configure the IPv6 addresses of one or more
- RDNSSes via RA message periodically sent by router or solicited by
+ RDNSSes via RA message periodically sent by router or solicited by
a Router Solicitation (RS) [8].
This approach needs RDNSS information to be configured in the
routers doing the advertisements. The configuration of RDNSS
address can be performed manually by operator or other ways, such
as automatic configuration through DHCPv6 client running on the
- router. When advertising more than one RDNSS options, an RA
- message includes as many RDNSS options as RDNSSes.
+ router. When advertising more than one RDNSS option, an RA message
+ includes as many RDNSS options as RDNSSes.
Through ND protocol and RDNSS option along with prefix information
option, an IPv6 host can perform its network configuration of its
However, it is worth noting that some link layers (e.g., WLAN) need
to acknowledge multicast packets, which may increase the amount of
- link-layer traffic. This is discussed in Appendix A.
+ link-layer traffic [25]-[28]. This is discussed in Appendix A.
The RA approach is useful in some mobile environments where the
addresses of the RDNSSes are changing because the RA option
includes a lifetime field that allows client to use RDNSSes nearer
to the client. This can be configured to a value that will require
the client to time out the entry and switch over to another RDNSS
- address [8]. However, from the viewpoint of implementation,
+ address [8]. However, from the viewpoint of implementation, the
lifetime would seem to make matters a bit more complex. Instead of
just writing DNS configuration file, such as resolv.conf for the
list of RDNSS addresses, we have to have a daemon around (or a
mechanisms [3][4], and does not require a change in the base ND
protocol.
- 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., Ethernet LANs), etc. RFC2461 [3] states, however,
-Jeong, et al. Expires - March 2005 [Page 4]
+Jeong, et al. Expires - August 2005 [Page 4]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- 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 obtained
- with the addition of this option to ND and address auto-
- configuration. The use of a single mechanism is more reliable and
- easier to provide than when the RDNSS information is learned via
- another protocol mechanism. Debugging problems when multiple
- protocol mechanisms are being used is harder and much more complex.
+ 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., Ethernet LANs), etc. RFC2461 [3] states,
+ however, that there may be some link types on which ND is not
+ possible; on such links, some other mechanisms will be needed for
+ DNS configuration.
+
+ 3) All of the information a host needs to run the basic Internet
+ applications such as the email, web, ftp, etc., can be obtained
+ 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 RDNSS 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. This works well on links that support broadcast
reliably (e.g., Ethernet LANs) but not necessarily on other links
- (e.g., Wireless LANs). Also, this works well on links that are
- high performance (e.g., Ethernet LANs) and low performance (e.g.,
- Cellular networks). In the latter case, combining the RDNSS
- 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 in a single packet. This not only
- saves bandwidth where this is an issue, but also minimizes the
- delay to learn the RDNSS information.
-
- 5) The RA approach could be used as a model for other similar types
+ (e.g., Wireless LANs): Refer to Appendix A. Also, this works well
+ on links that are high performance (e.g., Ethernet LANs) and low
+ performance (e.g., Cellular networks). In the latter case,
+ combining the RDNSS 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 in a single packet. This
+ not only saves bandwidth where this is an issue, but also minimizes
+ the delay needed to learn the RDNSS 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.
+ addresses, such as NTP server address, that are common to all
+ clients on a subnet would be easy to define.
3.1.2. Disadvantages
- 1) ND is mostly implemented in kernel part of operating system.
+ 1) ND is mostly implemented in the 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 complemented by a user-land process. DHCPv6,
- however, has more flexibility for extension of service discovery
- because it is an application layer protocol.
+ services, such as DNS servers, ND should be extended in the kernel
+ part, and complemented by a user-land process. DHCPv6, however,
+ has more flexibility for the extension of service discovery because
+ it is an application layer protocol.
2) The current ND framework should be modified due to the
- synchronization between another ND cache for RDNSSes in kernel
- space and DNS configuration file in user space. Because it is
- unacceptable to write and rewrite the DNS configuration file (e.g.,
- resolv.conf) from the kernel, another approach is needed. One
- simple approach to solve this is to have a daemon listening to what
- the kernel conveys, and to have the daemon do these steps, but such
- a daemon is not necessary with the current ND framework.
-
+ synchronization between another ND cache for RDNSSes in the kernel
+ space and the DNS configuration file in the user space. Because it
+ is unacceptable to write and rewrite the DNS configuration file
+ (e.g., resolv.conf) from the kernel, another approach is needed.
+ One simple approach to solve this is to have a daemon listening to
-Jeong, et al. Expires - March 2005 [Page 5]
+Jeong, et al. Expires - August 2005 [Page 5]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+ what the kernel conveys, and to have the daemon do these steps, but
+ such a daemon is not needed with the current ND framework.
+
3) It is necessary to configure RDNSS addresses at least at one
- router on every link where this information needs to be configured
+ router on every link where this information needs to be configured
by RA option.
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
- autoconfigure their addresses and all hosts on the subnet share the
- same router and server addresses. If the configuration information
- can be obtained from a single mechanism, it is preferable because
- it does not add additional delay, and it uses a minimum of
- bandwidth. Environments like this include homes, public cellular
- networks, and enterprise environments where no per host
- configuration is needed, but exclude public WLAN hot spots.
+ The proposed RDNSS RA option along with the IPv6 ND and
+ Autoconfiguration allows a host to obtain all of the information it
+ needs to access the basic Internet services like the web, email,
+ ftp, etc. This is preferable in the environments where hosts use
+ RAs to autoconfigure their addresses and all the hosts on the
+ subnet share the same router and server addresses. If the
+ configuration information can be obtained from a single mechanism,
+ it is preferable because it does not add additional delay, and it
+ uses a minimum of bandwidth. The environments like this include
+ the homes, public cellular networks, and enterprise environments
+ where no per host configuration is needed, but exclude public WLAN
+ hot spots.
DHCPv6 is preferable where it is being used for address
configuration and if there is a need for host specific
- configuration [5]-[7]. Environments like this are most likely
- enterprise environments where the local administration chooses to
- have per host configuration control.
+ configuration [5]-[7]. The environments like this are most likely
+ the enterprise environments where the local administration chooses
+ to have per host configuration control.
Note: the observation section is based on what the proponents of
each approach think makes a good overall solution.
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-
+ Reply message, in response to either a Request or an Information
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 [6].
- 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
+
-Jeong, et al. Expires - March 2005 [Page 6]
+Jeong, et al. Expires - August 2005 [Page 6]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+ 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.
The DHC Working Group is currently studying an additional mechanism
through which configuration information, including the list of
- RDNSSes, can be updated. The lifetime option for DHCPv6 [10]
+ 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,
large service provider networks with tens 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:
-
-Jeong, et al. Expires - March 2005 [Page 7]
+Jeong, et al. Expires - August 2005 [Page 7]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+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
- RDNSSes along with the addresses of other network services, as well
+ RDNSSes 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
addresses of SIP servers and NTP servers are likely to need DHCPv6
for other configuration information.
- 6) The specification for configuration of RDNSSes through DHCPv6 is
+ 6) The specification for configuration of RDNSSes through DHCPv6 is
available as an RFC. No new protocol extensions such as new
options are necessary.
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 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
-Jeong, et al. Expires - March 2005 [Page 8]
+Jeong, et al. Expires - August 2005 [Page 8]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+ a 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,
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
+ 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 RDNSSes or if hosts must be configured
selectively, those hosts will use DHCPv6 and the use of the DHCPv6
3.3. Well-known Anycast Addresses
+ Anycast uses the same routing system as unicast [11]. However,
+ administrative entities are local ones. The local entities may
+ accept unicast routes (including default routes) to anycast servers
+ from adjacent entities. The administrative entities should not
+ advertise their peers routes to their internal anycast servers, if
+ they want to prohibit external access from some peers to the
+ servers. If some advertisement is inevitable (such as the case
+ with default routes), the packets to the servers should be blocked
+ at the boundary of the entities. Thus, for this anycast, not only
+ unicast routing but also unicast ND protocols can be used as is.
+
First of all, the well-known anycast addresses approach is much
different from that discussed at IPv6 Working Group in the past [9].
It should be noted that "anycast" in this memo is simpler than that
anycast address. That is, on a link, anycast address is assumed to
be unique. DNS clients today already have redundancy by having
multiple well-known anycast addresses configured as RDNSS addresses.
- There is no point to have multiple RDNSSes sharing an anycast
+
+
+Jeong, et al. Expires - August 2005 [Page 9]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
+ There is no point in having multiple RDNSSes sharing an anycast
address on a single link.
-
- 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 [9].
+
+ The approach with well-known anycast addresses is to set multiple
+ 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 [9].
An anycast address is an address shared by multiple servers (in
this case, the servers are RDNSSes). Request from a client to the
servers and want to access their ISPs' across their site boundaries.
Larger sites may also depend on their ISPs or may have their own
RDNSSes within "site" boundaries.
-
-
-Jeong, et al. Expires - March 2005 [Page 9]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
3.3.1. Advantages
The basic advantage of the well-known addresses approach is that it
uses no transport mechanism. Thus,
- 1) There is no delay to get response and no further delay by packet
- losses.
+
+ 1) There is no delay to get the response and no further delay by
+ packet losses.
2) The approach can be combined with any other configuration
- mechanisms including but not limited to factory default
- configuration, RA-based approach and DHCP based approach.
+ mechanisms, such as RA-based approach and DHCP based approach, as
+ well as factory default configuration.
3) The approach works over any environment where DNS works.
effort is proportional to the number of the DNS servers and scales
linearly. It should be noted that, in the simplest case where a
subscriber to an ISP does not have any DNS server, the subscriber
- naturally accesses DNS servers of the ISP even though the subscriber
- and the ISP do nothing and there is no protocol to exchange DNS
- server information between the subscriber and the ISP.
+ naturally accesses DNS servers of the ISP even though the
+ subscriber and the ISP do nothing and there is no protocol to
+ exchange DNS server information between the subscriber and the ISP.
3.3.2. Disadvantages
- Well-known anycast addresses approach requires that DNS servers (or
+ Well-known anycast addresses approach requires that DNS servers (or
routers near it as a proxy) act as routers to advertise their
anycast addresses to the routing system, which requires some
configuration (see the last paragraph of the previous section on
the scalability of the effort).
+
+
+Jeong, et al. Expires - August 2005 [Page 10]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
3.3.3. Observations
If other approaches are used in addition, the well-known anycast
addresses should also be set in RA or DHCP configuration files to
- reduce configuration effort of users.
+ reduce the configuration effort of users.
- Redundancy by multiple RDNSSes is better provided by multiple
+ The redundancy by multiple RDNSSes is better provided by multiple
servers having different anycast addresses than multiple servers
- sharing same anycast address because the former approach allows
- stale servers to still generate routes to their anycast addresses.
+ sharing the same anycast address because the former approach allows
+ stale servers to still generate routes to their anycast addresses.
Thus, in a routing domain (or domains sharing DNS servers), there
- will be only one server having an anycast address unless the domain
+ will be only one server having an anycast address unless the domain
is so large that load distribution is necessary.
Small ISPs will operate one RDNSS at each anycast address which is
shared by all the subscribers. Large ISPs may operate multiple
-
-
-Jeong, et al. Expires - March 2005 [Page 10]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
RDNSSes at each anycast address to distribute and reduce load,
where boundary between RDNSSes may be fixed (redundancy is still
- provided by multiple addresses) or change dynamically. DNS packets
+ provided by multiple addresses) or change dynamically. DNS packets
with the well-known anycast addresses are not expected (though not
prohibited) to cross ISP boundaries, as ISPs are expected to be
able to take care of themselves.
- Because "anycast" in this memo is simpler than that of RFC1546 [11]
+ Because "anycast" in this memo is simpler than that of RFC1546 [11]
and RFC3513 [12] where it is assumed to be administratively
prohibited to have multiple servers on a single link sharing an
anycast address, anycast in this memo should be implemented as
addresses approach can and should use the anycast address as a
source unicast (according to RFC3513 [12]) address of packets of
UDP and TCP responses. With TCP, if route flips and packets to an
- anycast address are routed to a new server, it is expected that the
+ anycast address are routed to a new server, it is expected that the
flip is detected by ICMP or sequence number inconsistency and the
TCP connection is reset and retried.
option is included, an IPv6 host may perform DNS configuration
through DHCPv6 [5]-[7] 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
- 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 are 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 can not get RDNSS information through RA
- and DHCP. The well-known anycast addresses have to be pre-
- configured in IPv6 hosts' resolver configuration files.
-Jeong, et al. Expires - March 2005 [Page 11]
+Jeong, et al. Expires - August 2005 [Page 11]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- The second is that an IPv6 host can configure well-known addresses
- as the most preferable in its configuration file even though either
- RA option or DHCP option is available.
+ 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 are available.
+ That is, all the clients should have the well-known anycast
+ addresses preconfigured, in the case where there are no other
+ mechanisms available. In order to fly anycast approach with the
+ other solutions, there are three options as follows:
+
+ 1) The first option is that well-known addresses are used as last
+ resort, when an IPv6 host can not get RDNSS information through RA
+ and DHCP. The well-known anycast addresses have to be preconfigured
+ in IPv6 hosts' resolver configuration files.
- The last is that the well-known anycast addresses can be set in RA
- or DHCP configuration to reduce configuration effort of users.
+ 2) The second is that an IPv6 host can configure well-known
+ addresses as the most preferable in its configuration file even
+ though either 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 configuration effort of users.
According to either RA or DHCP mechanism, the well-known addresses
can be obtained by IPv6 host. Because this approach is the most
convenient for users, the last option is recommended.
- Note: this section does not necessarily mean this document suggests
+ Note: this section does not necessarily mean this document suggests
adopting all these three approaches and making them interwork in
the way described here. In fact, some approaches may even not be
adopted at all as a result of further discussion.
5. Deployment Scenarios
- Regarding DNS configuration on the IPv6 host, several mechanisms
- are being considered at 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.
+ Regarding the DNS configuration on the IPv6 host, several
+ mechanisms are being considered at 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
probable. The main objective of this work is to provide a useful
guideline for IPv6 DNS configuration.
+
+
+Jeong, et al. Expires - August 2005 [Page 12]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
5.1. ISP Network
A characteristic of ISP network is that multiple Customer Premises
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
+ This section discusses how the different approaches to distributing
DNS information are compared in an ISP network.
5.1.1. RA Option Approach
-
-
-Jeong, et al. Expires - March 2005 [Page 12]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
When the CPE is a host, the RA option for RDNSS can be used to
allow the CPE to get RDNSS information as well as /64 prefix
information for stateless address autoconfiguration at the same
which the host must receive at least an RA message for detecting a
new network, than in other scenarios generally although
administrator should configure RDNSS information on the routers.
- Secure ND [14] can provide extended security when using RA message.
+ Secure ND [14] 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
DNS option, and can provide other configuration information in the
same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option
- is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6-
- lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6
- implementation. DHCP is a client-server model protocol, so ISP can
+ is already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite
+ or stateless DHCP [6] 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 [15] can be used for secure message exchange.
+
+
+
+Jeong, et al. Expires - August 2005 [Page 13]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
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
can be carried in the same DHCPv6 message exchange used for DHCPv6
to efficiently provide that information, 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
+ 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.
Well-known anycast addresses approach is also a feasible and simple
mechanism for ISP [9]. The use of well-known anycast addresses
-
-
-Jeong, et al. Expires - March 2005 [Page 13]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
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
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 as RDNSS. RDNSS 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 [8]. As the first option in Section 4,
- well-known anycast addresses can be used as a last resort when
- RDNSS information can not be obtained through either RA option or
- DHCP option. This case needs IPv6 hosts to preconfigure the well-
- known anycast addresses in their DNS configuration files.
-
- When the enterprise prefers well-known anycast approach to the
+ requests from IPv6 hosts as RDNSSes. The RDNSS configuration in
+ the enterprise network can be performed like in Section 4, in which
+ three approaches can be used together as follows:
+
+ 1) IPv6 host can decide which approach is or may be used in its
+ subnet with O flag in RA message [8]. As the first option in
+ Section 4, well-known anycast addresses can be used as a last
+ resort when RDNSS information can not be obtained through either RA
+ option or DHCP option. This case needs IPv6 hosts to preconfigure
+ the well-known anycast addresses in their DNS configuration files.
+
+
+
+Jeong, et al. Expires - August 2005 [Page 14]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
+ 2) 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
+ 3) 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
architecture can be found in [18], and transition to IPv6 in 3GPP
networks is analyzed in [19] and [20].
-
-
-Jeong, et al. Expires - March 2005 [Page 14]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
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 [21].
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).
+ received in the PDP context activation (a control plane mechanism).
That is called the Protocol Configuration Options Information
Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be
received over the air (using text messages), or typed in manually
RDNSS addresses manually in his/her UE. The use of well-known
addresses is briefly discussed in section 5.3.4.
+
+
+Jeong, et al. Expires - August 2005 [Page 15]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
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
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,
-
-
-Jeong, et al. Expires - March 2005 [Page 15]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
WLAN and other access network technologies. A light, stateless
IPv6 DNS configuration mechanism is thus not only needed in 3GPP
networks, but also 3GPP networks and UEs would certainly benefit
should, however, be pretty straightforward, and new IPv6 equipment
could support RA extension already from the beginning.
+
+
+
+Jeong, et al. Expires - August 2005 [Page 16]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
5.3.3. Stateless DHCPv6
DHCPv6-based solution needs the implementation of Stateless DHCP
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
server, the RDNSS configuration information can be updated by the
network administrator at a single source.
-
-
-Jeong, et al. Expires - March 2005 [Page 16]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
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.
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
+ 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
+ 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 [23].
+
+
+Jeong, et al. Expires - August 2005 [Page 17]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
5.3.4. Well-known Addresses
- Using well-known addresses is also a feasible and a light mechanism
+ 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
any of the preconfigured addresses. In the current proposal [9],
IPv6 anycast addresses are suggested.
- Note: IPv6 DNS configuration proposal based on the use of well-
- known site-local addresses developed at 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
+ Note: IPv6 DNS configuration proposal based on the use of
+ well-known site-local addresses developed at 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 of IPv6 DNS configuration.
+ (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
5.3.5. Recommendations
-
-
-Jeong, et al. Expires - March 2005 [Page 17]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
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
not provide IPv6. Automatic or Configured tunnels are the
recommended transition mechanisms for this scenario.
+
+
+
+Jeong, et al. Expires - August 2005 [Page 18]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
The case where dual-stack hosts behind an NAT, that need access to
an IPv6 RDNSS, can not be entirely ruled out. The DNS
configuration mechanism has to work over the tunnel, and the
RA-based mechanism is relatively straightforward in its operation,
assuming the tunnel server is also the IPv6 router emitting RAs.
Well-known anycast addresses approach seems also 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.
+ 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
Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
DHCP server is stateful (maintains the state for clients).
-
-
-
-Jeong, et al. Expires - March 2005 [Page 18]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
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
secure full autoconfiguration will get false security, false
autoconfiguration or both.
- In some deployment scenario [19], 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 depend on DNS, the applications also require
- cryptographic security to DNS. Therefore, the full auto-
- configuration of DNS is not acceptable.
+ In some deployment scenarios [19], 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
+
+
+Jeong, et al. Expires - August 2005 [Page 19]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
+ securely configured. It should be noted 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 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.
+ 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
+ the acceptable security.
+
+ In autoconfiguring recursive servers, DNSSEC may be overkill,
+ because DNSSEC [29] needs the configuration and reconfiguration of
+ clients at root key roll-over [30][31]. 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
+ attacks, 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, it requires configured
+ secret information.
+
+ If DNSSEC [29] is used and the signatures are verified on the
+ client host, the misconfiguration of a DNS server may be simply
+ 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.
For security considerations of each approach, refer to the
corresponding drafts [5]-[9].
7. Acknowledgements
-
-
-
-Jeong, et al. Expires - March 2005 [Page 19]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
This draft has greatly benefited from inputs by David Meyer, Rob
Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
- The authors appreciate their contribution.
+ The authors appreciate their contributions.
8. Normative References
[1] S. Bradner, "Intellectual Property Rights in IETF Technology",
RFC 3668, February 2004.
+
+
+Jeong, et al. Expires - August 2005 [Page 20]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
[2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February
2004.
9. Informative References
[8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS
- Discovery based on Router Advertisement", draft-jeong-dnsop-
- ipv6-dns-discovery-02.txt, July 2004, Work in Progress.
+ Discovery based on Router Advertisement",
+ draft-jeong-dnsop-ipv6-dns-discovery-04.txt, February 2005,
+ Work in Progress.
- [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta-
- preconfigured-dns-01.txt, February 2004, Work in Progress.
+ [9] M. Ohta, "Preconfigured DNS Server Addresses",
+ draft-ohta-preconfigured-dns-01.txt, February 2004, Work in
+ Progress.
- [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time
- Option for DHCPv6", draft-ietf-dhc-lifetime-02.txt, September
- 2004, Work in Progress.
+ [10] S. Venaas, T. Chown and B. Volz, "Information Refresh Time
+ Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt, January
+ 2005, Work in Progress.
[11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
+ [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
+ into ISP Networks",
+ draft-ietf-v6ops-isp-scenarios-analysis-03.txt, June 2004,
+ Work in Progress.
+
+ [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)",
+ draft-ietf-send-ndopt-06.txt, July 2004, Work in Progress.
+
-Jeong, et al. Expires - March 2005 [Page 20]
+Jeong, et al. Expires - August 2005 [Page 21]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6
- into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis-
- 03.txt, June 2004, Work in Progress.
-
- [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft-
- ietf-send-ndopt-06.txt, July 2004, Work in Progress.
-
[15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001.
- [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft-
- ietf-v6ops-ent-scenarios-05.txt, July 2004, Work in Progress.
+ [16] J. Bound et al., "IPv6 Enterprise Network Scenarios",
+ draft-ietf-v6ops-ent-scenarios-05.txt, July 2004, Work in
+ Progress.
[17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December
RFC 3574, August 2003.
[20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP
- Networks", draft-ietf-v6ops-3gpp-analysis-10.txt, May 2004,
+ Networks", draft-ietf-v6ops-3gpp-analysis-11.txt, October 2004,
Work in Progress.
[21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
June 2003.
[23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering
- Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless-
- dhcpv6-renumbering-01.txt, March 2004, Work in Progress.
+ Requirements for Stateless DHCPv6",
+ draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt, October
+ 2004, Work in Progress.
[24] C. Huitema et al., "Unmanaged Networks IPv6 Transition
Scenarios", RFC 3750, April 2004.
-10. Appendix A - Link-layer Multicast Acknowledgements with RA Option
+ [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) Specifications", March
+ 1999.
- One benefit of RA option is to be able to multicast the
- advertisements, reducing the need for duplicated unicast
- communications.
+ [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) specifications: High-speed
+ Physical Layer in the 5 GHZ Band", September 1999.
+
+ [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) specifications: Higher-Speed
+ Physical Layer Extension in the 2.4 GHz Band", September 1999.
-
-Jeong, et al. Expires - March 2005 [Page 21]
+Jeong, et al. Expires - August 2005 [Page 22]
\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
- However, some link-layers may not support this as well as others.
+ [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) specifications: Further
+ Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
+
+ [29] D. Eastlake, "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [30] O. Kolkman and R. Gieben, "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practices-03.txt,
+ December 2004.
+
+ [31] G. Guette and O. Courtay, "Requirements for Automated Key
+ Rollover in DNSSEC",
+ draft-ietf-dnsop-key-rollover-requirements-02.txt, January
+ 2005.
+
+10. Appendix A - Link-layer Multicast Acknowledgements with RA Option
+
+ One benefit of RA option is to be able to multicast the
+ advertisements, reducing the need for duplicated unicast
+ communications.
+
+ However, some link-layers may not support this as well as others.
Consider, for example, WLAN networks where multicast is unreliable.
The unreliability problem is caused by lack of ACK for multicast,
especially on the path from the Access Point (AP) to the Station
- (STA), which is specific to CSMA/CA of WLAN. Namely, multicast
- packet is unacknowledged on the path from the AP to the STA, but
- acknowledged in the reverse direction from the STA to the AP. For
- example, when a router is placed at wired network connected to an
- AP, a host may sometimes not receive RA message advertised through
- the AP.
+ (STA), which is specific to CSMA/CA of WLAN [25]-[28]. Namely,
+ multicast packet is unacknowledged on the path from the AP to the
+ STA, but acknowledged in the reverse direction from the STA to the
+ AP [25]. For example, when a router is placed at wired network
+ connected to an AP, a host may sometimes not receive RA message
+ advertised through the AP.
The fact that this problem has not been addressed in Neighbor
Discovery [3] indicates that the extra link-layer acknowledgements
have not been considered a serious problem till now.
- A possible mitigation technique could be to map all-nodes link-
- local multicast address to the link-layer broadcast address, and to
- rely on the ND retransmissions for message delivery.
+ A possible mitigation technique could be to map all-nodes link-local
+ multicast address to the link-layer broadcast address, and to rely
+ on the ND retransmissions for message delivery.
11. Authors' Addresses
117 Pleasant Street SE
Minneapolis, MN 55455
USA
+
+
+Jeong, et al. Expires - August 2005 [Page 23]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
Phone: +1 651 587 7774
EMail: jjeong@cs.umn.edu
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
-
-
-Jeong, et al. Expires - March 2005 [Page 22]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
Ted Lemon
Nominum, Inc.
950 Charter Street
Korea
Phone: +82 31 200 4508
+
+
+Jeong, et al. Expires - August 2005 [Page 24]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
EMail: soohong.park@samsung.com
Suresh Satapati
12. Intellectual Property Statement
- The following intellectual property notice is copied from RFC3668,
- Section 5.
-
-
-Jeong, et al. Expires - March 2005 [Page 23]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server September 2004
-
-
-
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
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.
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
-Full Copyright Statement
+13. Full Copyright Statement
- The following copyright notice is copied from RFC3667, Section 5.4.
- It describes the applicable copyright for this document.
-
- Copyright (C) The Internet Society (2004). This document is
+ Copyright (C) The Internet Society (2005). 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.
-
+ rights.
+
+
+Jeong, et al. Expires - August 2005 [Page 25]
+\f
+Internet-Draft IPv6 Host Configuration of DNS Server February 2005
+
+
+
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
Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Jeong, et al. Expires - March 2005 [Page 24]
+Jeong, et al. Expires - August 2005 [Page 26]
\f
-
projects / thirdparty / bind9.git / commitdiff
