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/ |