draft-ietf-ipv6-dns-discovery-05.txt   draft-ietf-ipv6-dns-discovery-06.txt 
Network Working Group Alain Durand Network Working Group Alain Durand
INTERNET-DRAFT SUN Microsystems, inc. INTERNET-DRAFT SUN Microsystems, inc.
June 14, 2002 Jun-ichiro itojun Hagino August 21, 2002 Jun-ichiro itojun Hagino
Expires December 2002 IIJ Research Laboratory Expires February 2002 IIJ Research Laboratory
Dave Thaler Dave Thaler
Microsoft Microsoft
Well known site local unicast addresses for DNS resolver Well known site local unicast addresses for DNS resolver
<draft-ietf-ipv6-dns-discovery-05.txt> <draft-ietf-ipv6-dns-discovery-06.txt>
Status of this Memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet Drafts are valid for a maximum of six months and may be Internet Drafts are valid for a maximum of six months and may be
skipping to change at line 33 skipping to change at line 33
is inappropriate to use Internet Drafts as reference material or to is inappropriate to use Internet Drafts as reference material or to
cite them other than as a "work in progress". cite them other than as a "work in progress".
To view the list Internet-Draft Shadow Directories, see To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This documents specifies a method for nodes to find a DNS resolver This documents specifies a method for nodes to find a DNS resolver
with minimum configuration in the network and without running a with minimum configuration in the network and without running a
discovery protocol on the nodes. discovery protocol on the nodes. This method is to be used in last
resort, when no other information about the addresses of DNS
resolvers is available.
Copyright Notice Copyright notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
1. Introduction 1. Introduction
RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
more IPv6 address and default routes. more IPv6 address and default routes.
However, for a node to be fully operational on a network, many other However, for a node to be fully operational on a network, many other
parameters are needed, such as the address of a DNS resolver, mail parameters are needed, such as the address of a DNS resolver, mail
skipping to change at line 89 skipping to change at line 91
One avenue is to ask the IPv6 node to participate in a discovery One avenue is to ask the IPv6 node to participate in a discovery
protocol, such as SLP or DHCP, learn the address of the server and protocol, such as SLP or DHCP, learn the address of the server and
send packets to this server. Another one is to pre-configure (hard- send packets to this server. Another one is to pre-configure (hard-
code) a local scope address on the IPv6 node and let it send packets code) a local scope address on the IPv6 node and let it send packets
directly to this address, with the underlying assumption that the directly to this address, with the underlying assumption that the
routing system will forward them to the right place. This document routing system will forward them to the right place. This document
explores this later avenue of pre-configuration that does not require explores this later avenue of pre-configuration that does not require
participation of the end node in the DNS resolver discovery participation of the end node in the DNS resolver discovery
mechanism. mechanism.
The mechanism described here is to be used as a last resort, when no The mechanism described here is to be used as a last resort, in the
other configuration information is available. absence of any information about the addresses of DNS resolvers. If
other configuration mechanisms are available, they should be tried
first.
3. Reserved Prefix and addresses Note to implementors:
The basic idea of this proposal is to reserve a well known IPv6 site Implementing only the mechanism described in this memo may end up
local prefix and three well known IPv6 addresses for DNS resolvers causing some interoperability problems when operating in networks
and then have the routing system forward the DNS request to those DNS where no DNS resolver is configured with the well known addresses.
resolvers. Thus, it is recommended to implement also other mechanisms for
overriding this default, for example: manual configuration, L2
mechanisms and/or DHCPv6.
IPv6 nodes will be pre-configured (hard coded) with those three IPv6 3. Reserved prefix and addresses
addresses as DNS resolver.
Each local DNS resolvers should be configured with one of those three The basic idea of this proposal is to reserve three well known IPv6
site local addresses for DNS resolvers and then have the routing
system forward the DNS request to them.
IPv6 stub-resolvers implementing this proposal are pre-configured
with those three IPv6 addresses as DNS resolver.
Local DNS resolvers should be configured with one of those three
addresses to enable clients to switch from one to the other if one addresses to enable clients to switch from one to the other if one
fails. Host routes for each of those resolvers should be injected in fails.
the local routing system. Example methods for injecting host routes
and a brief discussion of their fate sharing properties is presented A solution to enable clients to reach the DNS resolvers is to inject
here: host routes in the local routing system. Examples of methods for
injecting host routes and a brief discussion of their fate sharing
properties are presented here:
a) Manual injection of routes by a router on the same subnet. a) Manual injection of routes by a router on the same subnet.
If the node running the DNS resolver goes down, the router may or If the node running the DNS resolver goes down, the router may or
may not be notified and keep announcing the route. may not be notified and keep announcing the route.
b) Running a routing protocol on the same node running the DNS b) Running a routing protocol on the same node running the DNS
resolver. resolver.
If the process running the DNS resolver dies, the routing protocol If the process running the DNS resolver dies, the routing protocol
may or may not be notified and keep annoucing the route. may or may not be notified and keep annoucing the route.
c) Running a routing protocol within the same process running the c) Running a routing protocol within the same process running the
DNS resolver. DNS resolver.
If the DNS resolver and the routing protocol run in separated If the DNS resolver and the routing protocol run in separated
threads, similar concerns as above are true. threads, similar concerns as above are true.
d) Having an "announcement" protocol that the DNS resolver could d) Having an "announcement" protocol that the DNS resolver could
use to advertize the host route to the nearby router. use to advertize the host route to the nearby router. Details of
Details of such a protocols are out of scope of this document, but such a protocols are out of scope of this document, but something
something similar to [MLD] is possible. similar to [MLD] is possible.
An alternate solution is to configure a link with the well known
prefix and position the three DNS resolvers on that link. The
advantage of this method is that host routes are not necessary , the
well known prefix is advertized to the routing system by the routers
on the link. However, in the event of a problem on the physical link,
all resolvers will become unreachable.
IANA considerations for this prefix are covered in Section 6. IANA considerations for this prefix are covered in Section 6.
4. Site local versus global scope considerations 4. Site local versus global scope considerations
The rationales for having a site local prefix are: The rationales for having a site local prefix are:
-a) Using a site local prefix will ensure that the traffic to the -a) Using a site local prefix will ensure that the traffic to the
DNS resolver stays local to the site. This will prevent the DNS DNS resolver stays local to the site. This will prevent the DNS
requests from accidentally leaking out of the site. However, the requests from accidentally leaking out of the site. However, the
local resolver can implement a policy to forward DNS resolution of local resolver can implement a policy to forward DNS resolution of
non-local addresses to an external DNS resolver. non-local addresses to an external DNS resolver.
-b) Reverse DNS resolution of site local addresses is only -b) Reverse DNS resolution of site local addresses is only
meaningful within the site. Thus, making sure that such queries meaningful within the site. Thus, making sure that such queries
are first sent to a DNS resolver located within the site perimeter are first sent to a DNS resolver located within the site perimeter
increase their likelyhood of success. increase their likelyhood of success.
Note: there is currently some discussions about the usefulness of
site local addresses in the IPv6 architecture. Depending on the
outcome of this discussion, this section will need to be revisited.
If a global prefix was chosen for this mechanism, concerns raised in
a) could be addressed using a simple access list on the site exit
routers and concerns raised in b) would disappear.
5. Examples of use 5. Examples of use
This section presents example scenarios showing how the mechanism This section presents example scenarios showing how the mechanism
described in this memo can co-exist with other techniques, namely described in this memo can co-exist with other techniques, namely
manual configuration and DHCPv6 discovery. manual configuration and DHCPv6 discovery.
5.1 Simple case, general purpose DNS resolver 5.1 Simple case, general purpose DNS resolver
This example shows the case of an enterprise or a cellular network This example shows the case of an enterprise or a cellular network
that manages a full flavor general purpose DNS resolver and a large that manages a full flavor general purpose DNS resolver and a large
skipping to change at line 198 skipping to change at line 212
5.2 DNS forwarder 5.2 DNS forwarder
A drawback of the choice of site local scope for the reserved A drawback of the choice of site local scope for the reserved
addresses for DNS resolver is that, in the case of a home/small addresses for DNS resolver is that, in the case of a home/small
office network connected to an ISP, DNS traffic cannot be sent office network connected to an ISP, DNS traffic cannot be sent
directly to the ISP DNS resolver without having the ISP and all its directly to the ISP DNS resolver without having the ISP and all its
customers share the same definition of site. customers share the same definition of site.
In this scenario, the home/small office network is connected to the In this scenario, the home/small office network is connected to the
ISP router (PE) via an edge router (CPE). Prefix delegation is ISP router (PE) via an edge router (CPE).
performed out of band is is out of scope of this memo.
------------- -------------
/ | / |
-------- -------------- / | -------- -------------- / |
|ISP PE| |customer CPE| / Customer | |ISP PE| |customer CPE| / Customer |
| |===========| |====< site | | |===========| |====< site |
| | | | \ | | | | | \ |
-------- -------------- \ | -------- -------------- \ |
\ | \ |
------------- -------------
skipping to change at line 232 skipping to change at line 245
|DNS |===========| DNS|====< site | |DNS |===========| DNS|====< site |
|resolver| <------|---forwarder|-----\---- | |resolver| <------|---forwarder|-----\---- |
---------- -------------- \ | ---------- -------------- \ |
\ | \ |
------------- -------------
In this configuration, the CPE is acting as a multi-sited router. In this configuration, the CPE is acting as a multi-sited router.
5.3 DNS forwarder with DHCPv6 interactions 5.3 DNS forwarder with DHCPv6 interactions
In this variant scenario, DHCPv6 could be used between the PE and CPE In this variant scenario, DHCPv6 is be used between the PE and CPE to
to do prefix delegation [DELEG] and DNS resolver discovery. do prefix delegation [DELEG] and DNS resolver discovery.
------------- -------------
/ | / |
-------- -------------- / | -------- -------------- / |
|ISP | |customer CPE| / Customer | |ISP | |customer CPE| / Customer |
|DHCPv6|===========| DHCPv6|====< site | |DHCPv6|===========| DHCPv6|====< site |
|server| <------|------client| \ | |server| <------|------client| \ |
-------- -------------- \ | -------- -------------- \ |
\ | \ |
------------- -------------
This example will show how DHCPv6 and well known site local unicast This example will show how DHCPv6 and well known site local unicast
addresses can be used at the same time within a site to discover the addresses cooperate to enable the internal nodes to access DNS.
address of the DNS forwarder.
The customer router CPE could be configured on its internal interface The customer router CPE is configured on its internal interface with
with one of the reserved site local addresses and listen for DNS one of the reserved site local addresses and listen for DNS queries.
queries. It would act as a DNS forwarder, forwarding those queries to It would act as a DNS forwarder, as in 5.2, forwarding those queries
the DNS resolver pointed out by the ISP in the DHCPv6 exchange. to the DNS resolver pointed out by the ISP in the DHCPv6 exchange.
------------- -------------
/ | / |
---------- -------------- / | ---------- -------------- / |
|ISP | |customer CPE| / Customer | |ISP | |customer CPE| / Customer |
|DNS |===========| DNS|====< site | |DNS |===========| DNS|====< site |
|resolver| <------|---forwarder|-----\---- | |resolver| <------|---forwarder|-----\---- |
---------- -------------- \ | ---------- -------------- \ |
\ | \ |
------------- -------------
The same CPE router could also act as a local DHCPv6 server, The same CPE router could also implement a local DHCPv6 server and
advertising either itself as DNS forwarder. advertises itself as DNS forwarder.
------------- -------------
/ | / |
-------- -------------- / Customer | -------- -------------- / Customer |
|ISP PE| |customer CPE| / site | |ISP PE| |customer CPE| / site |
| |===========|DHCPv6 |====< | | |===========|DHCPv6 |====< |
| | |server------|-----\---> | | | |server------|-----\---> |
-------- -------------- \ | -------- -------------- \ |
\ | \ |
------------- -------------
Within the site: Within the site:
a) DHCPv6 aware clients could use DHCPv6 to obtain the address of a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
the DNS forwarder... DNS forwarder...
------------- -------------
/ | / |
---------- -------------- / Customer | ---------- -------------- / Customer |
|ISP | |customer CPE| / site | |ISP | |customer CPE| / site |
|DNS |===========| DNS|====< | |DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----DHCPv6 | |resolver| <------|---forwarder|-----\----DHCPv6 |
---------- -------------- \ client | ---------- -------------- \ client |
\ | \ |
------------- -------------
(The address of the DNS forwarder is aquired via DHCPv6.) (The address of the DNS forwarder is aquired via DHCPv6.)
b) other nodes may simply send their DNS request to the reserved b) other nodes simply send their DNS request to the reserved site
site local addresses. local addresses.
------------- -------------
/ | / |
---------- -------------- / customer | ---------- -------------- / customer |
|ISP | |customer CPE| / site | |ISP | |customer CPE| / site |
|DNS |===========| DNS|====< | |DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----non DHCPv6| |resolver| <------|---forwarder|-----\----non DHCPv6|
---------- -------------- \ node | ---------- -------------- \ node |
\ | \ |
------------- -------------
skipping to change at line 317 skipping to change at line 329
A variant of this scenario is the CPE can decide to pass the global A variant of this scenario is the CPE can decide to pass the global
address of the ISP DNS resolver in the DHCPv6 exchange with the address of the ISP DNS resolver in the DHCPv6 exchange with the
internal nodes. internal nodes.
6. IANA considerations 6. IANA considerations
The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
of the site local fec0::/10 prefix. of the site local fec0::/10 prefix.
The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
and fec0:000:0000:ffff::2 are to be reserved for DNS resolver and fec0:000:0000:ffff::3 are to be reserved for DNS resolver
configuration. configuration.
All other addresses within the fec0:0000:0000:ffff::/64 are reserved All other addresses within the fec0:0000:0000:ffff::/64 are reserved
for future use and are expected to be assigned only with IESG for future use and are expected to be assigned only with IESG
approval. approval.
7. Security Considerations 7. Security Considerations
Ensuring that queries reach a legitimate DNS server relies on the Ensuring that queries reach a legitimate DNS server relies on the
security of the IPv6 routing infrastructure. The issues here are the security of the IPv6 routing infrastructure. The issues here are the
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/