draft-ietf-ipv6-dns-discovery-04.txt | draft-ietf-ipv6-dns-discovery-05.txt | |||
---|---|---|---|---|
Network Working Group Alain Durand | ||||
INTERNET-DRAFT SUN Microsystems, inc. | ||||
June 14, 2002 Jun-ichiro itojun Hagino | ||||
Expires December 2002 IIJ Research Laboratory | ||||
Dave Thaler | ||||
Microsoft | ||||
Network Working Group Dave Thaler | Well known site local unicast addresses for DNS resolver | |||
INTERNET-DRAFT Microsoft | <draft-ietf-ipv6-dns-discovery-05.txt> | |||
March 1, 2002 Jun-ichiro itojun Hagino | ||||
Expires August 2002 IIJ Research Laboratory | ||||
IPv6 Stateless DNS Discovery | ||||
<draft-ietf-ipv6-dns-discovery-04.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 | |||
updated, replaced, or obsoleted by other documents at any time. | updated, replaced, or obsoleted by other documents at any time. It | |||
It is inappropriate to use Internet Drafts as reference material | is inappropriate to use Internet Drafts as reference material or to | |||
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 document specifies the steps a host takes in deciding how to | This documents specifies a method for nodes to find a DNS resolver | |||
autoconfigure the addresses of DNS Servers required for name | with minimum configuration in the network and without running a | |||
resolution in IP version 6. The autoconfiguration process | discovery protocol on the nodes. | |||
includes determining whether such information should be obtained | ||||
through the stateless mechanism, the stateful mechanism, or both. | ||||
This document defines the process for acquiring a list of DNS | ||||
server addresses. Approaches for acquiring a domain search path, | ||||
and the domain name of the host via a stateless mechanism are | ||||
Draft Stateless DNS Discovery March 2002 | ||||
included in an appendix for further study. The details of | ||||
autoconfiguration using the stateful protocol are specified | ||||
elsewhere. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
Draft Stateless DNS Discovery March 2002 | ||||
1. Introduction | 1. Introduction | |||
RFC 2462 [ADDRCONF] specifies "OtherConfigFlag" as a per-interface | RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or | |||
variable, which is set from the value of the "O" ("Other stateful | more IPv6 address and default routes. | |||
configuration") flag in Router Advertisements received. When | ||||
OtherConfigFlag is set on an interface, information related to | ||||
name resolution is obtained using the stateful autoconfiguration | ||||
mechanism. However, when OtherConfigFlag is not set, it does not | ||||
describe how to obtain such information. This is the purpose of | ||||
this document. | ||||
For a host to effectively resolve names of other hosts, and | ||||
potentially allow resolution of its name to be performed, the | ||||
following parameters are typically required: | ||||
o One or more addresses of Domain Name Service (DNS) [RFC1034, | ||||
RFC1035] servers. The function of name-to-address resolution | ||||
(or vice versa) in IP is performed by DNS, which requires that | ||||
at least one DNS Server be known and reachable by a device | ||||
desiring to perform name resolution. | ||||
o A per-interface domain name of the host itself, and is | ||||
equivalent to the Domain Name option in [DHCP]. This can be | ||||
used when Multicast DNS is enabled, and the host responds to | ||||
queries for its own name, as well as when DNS Dynamic Update is | ||||
enabled. Depending on the implementation, the per-interface | ||||
domain name may or may not be the same thing as the primary | ||||
domain name of the host. | ||||
o Search path. It is currently common practice for the search | ||||
path to be computed by a device based on its domain name(s). | ||||
However, a DHCP option [DOMSEARCH] has been proposed, and so | ||||
search path configuration is likely to be a requirement in | ||||
general. | ||||
o mDNS-enabled flag. This parameter controls whether Multicast | ||||
DNS [MDNS] should be enabled on the host's interface. | ||||
A design team recommendation [DDDT] contains an analysis of the | ||||
requirements and solution space, which was used as the basis for | ||||
this document. One result of this analysis was that there is a | ||||
spectrum of configuration/discovery mechanisms. At one end, a | ||||
single protocol is used to configure/discovery all types of | ||||
information. This style works well in an administered environment | ||||
where a network administrator wants to have a central point of | ||||
Draft Stateless DNS Discovery March 2002 | ||||
control, and apply policies, etc. At the other end, each protocol | ||||
is self-configuring, rather than depending on any other protocol | ||||
or server. This style provides optimal fate sharing, and works | ||||
well in zero-configuration environments such as adhoc networks and | ||||
simple networks without network administrator staff. The former | ||||
mechanism is used with the "Other stateful configuration" flag is | ||||
used, and this draft provides the benefits (and limitations) of | ||||
the latter approach when "Other stateful configuration" is not | ||||
set. | ||||
Note: This document only includes in its body a solution for | ||||
obtaining the address of Domain Name Service servers. Mechanisms | ||||
for obtaining the other parameters listed above are included in an | ||||
Appendix A for further study. These may be moved to a separate | ||||
document in the future. | ||||
2. Overview | ||||
A set of three well-known site-local IPv6 addresses are reserved | ||||
for autodiscovery of DNS servers. These addresses may be used as | ||||
unicast addresses assigned to different servers. The use of the | ||||
addresses as anycast addresses with one of them being assigned to | ||||
all DNS servers in the site, or any combination of anycast and | ||||
unicast addresses, is for further study. | ||||
Host routes for these addresses are propagated in the site's | ||||
routing tables. This document proposes that these three addresses | ||||
be: | ||||
fec0:0:0:ffff::1 | ||||
fec0:0:0:ffff::2 | ||||
fec0:0:0:ffff::3 | ||||
This list of three addresses may be hardcoded into a host. | ||||
Furthermore, we define two levels of functionality. Level 1 is | ||||
defined below. Level 2 is described in Appendix A and is for | ||||
further study. | ||||
Draft Stateless DNS Discovery March 2002 | ||||
3. Level 1 Compliance | ||||
Level 1 compliance entails using the three addresses above for | ||||
actual name resolution. It provides only rudimentary | ||||
functionality. In particular, it does not provide the ability to | ||||
have separate configuration for hosts on different subnets, nor to | ||||
provide hosts with a domain name other than one for which the DNS | ||||
server is authoritative. | ||||
3.1. DNS Server Configuration | ||||
Level 1 functionality requires no DNS server configuration other | ||||
than assigning one of the well-known addresses to one of the | ||||
server's interfaces. A host route must then be injected into the | ||||
routing domain, e.g., by configuring a static host route on the | ||||
server's router, and redistributing it into the intra-domain | ||||
routing protocol. | ||||
A host route must then be injected into the site's routing | ||||
infrastructure. Route injection can be done via any of several | ||||
methods, including but not limited to: | ||||
a) Run the server on a router, and configure it to inject the host | ||||
route. | ||||
b) Run a routing protocol on the server, and configure it to | ||||
inject the host route. Note that this requires that the server | ||||
and its router(s) must run the same routing protocol, at least | ||||
for communication between the router(s) and the server(s) on | ||||
the link. However, a server does not need to participate fully | ||||
in the routing protocol, it only needs to be able to inject | ||||
routes. | ||||
c) Run multiple servers on the same link(s), and configure their | ||||
local router(s) to inject host routes for the well-known | ||||
address into the site's routing infrastructure. Running | ||||
multiple servers on the same link provides robustness to the | ||||
failure of a server, while routing provides robustness to the | ||||
loss of routers and other links. There may still be some | ||||
failures, however, such as a unidirectional failure of the | ||||
router's interface, which are not handled by this option. | ||||
d) Modify the routers on the link to periodically solicit (using | ||||
Neighbor Discovery) the well-known address, and inject the | ||||
Draft Stateless DNS Discovery March 2002 | ||||
host route based on whether a reply is received. | 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 | ||||
relays, web proxies, etc. Except for name resolution, all the other | ||||
services are usually described using names, not addresses, such as | ||||
smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping | ||||
reasons, a node needs to be configured with the IP address (and not | ||||
the name) of a DNS resolver. As IPv6 addresses look much more | ||||
complex than IPv4 ones, there is some incentive to make this | ||||
configuration as automatic and simple as possible. | ||||
3.2. Host Behavior | Although it would be desirable to have all configuration parameters | |||
configured/discovered automatically, it is common practice in IPv4 | ||||
today to ask the user to do manual configuration for some of them by | ||||
entering server names in a configuration form. So, a solution that | ||||
will allow for automatic configuration of the DNS resolver is seen as | ||||
an important step forward in the autoconfiguration story. | ||||
The host sets its DNS server list equal to the set of three | The intended usage scenario for this proposal is a home or enterprise | |||
addresses listed above. The search path is not discovered, but is | network where IPv6 nodes are plugged/unplugged with minimum | |||
generated from the host's domain name(s) as is currently common | management and use local resources available on the network to | |||
practice. If desired, a per-interface domain name can be obtained | autoconfigure. This proposal is also usefull in cellular networks | |||
by sending a query (with the Recursion Desired (RD) bit set), | where all moble devices are included within the same site. | |||
doing a reverse lookup for the well-known site-local IPv6 | ||||
destination address, and extracting the domain name from the NS | ||||
record in the reply. | ||||
4. Security Considerations | 2. Pre-configuration vs discovery | |||
Ensuring that queries reach a legitimate DNS server relies on the | Some of the discussions in the past around DNS server discovery have | |||
security of the IPv6 routing infrastructure. The issues here are | been trying to characterize the solution space into stateless versus | |||
the same as those for protecting basic IPv6 connectivity. | stateful or server-oriented versus severless. It is not absolutely | |||
clear how much state if any needs to be kept to perform DNS server | ||||
discovery, and, although the semantic differences between a router | ||||
and a server are well understood from a conceptual perspective, the | ||||
current implementations tend to blur the picture. In another attempt | ||||
to characterize different approaches, one can look at how much | ||||
intelligence a client needs to have in order to use the service. | ||||
IPsec/IKE can be used when the well-known addresses are used as | One avenue is to ask the IPv6 node to participate in a discovery | |||
unicast addresses. | 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- | ||||
code) a local scope address on the IPv6 node and let it send packets | ||||
directly to this address, with the underlying assumption that the | ||||
routing system will forward them to the right place. This document | ||||
explores this later avenue of pre-configuration that does not require | ||||
participation of the end node in the DNS resolver discovery | ||||
mechanism. | ||||
The payload can be protected as follows. If the client can | The mechanism described here is to be used as a last resort, when no | |||
preconfigure a well known private or public key then TSIG [TSIG] | other configuration information is available. | |||
can be used with the same packets presented for the query. If | ||||
this is not the case, then TSIG keys will have to be negotiated | ||||
using [TKEY]. After the client has the proper key then the query | ||||
can be performed. | ||||
5. IANA Considerations | 3. Reserved Prefix and addresses | |||
The IANA should assign the following site-local IPv6 addresses to | The basic idea of this proposal is to reserve a well known IPv6 site | |||
be used as well-known addresses assigned to DNS servers: | local prefix and three well known IPv6 addresses for DNS resolvers | |||
and then have the routing system forward the DNS request to those DNS | ||||
resolvers. | ||||
fec0:0:0:ffff::1 | IPv6 nodes will be pre-configured (hard coded) with those three IPv6 | |||
fec0:0:0:ffff::2 | addresses as DNS resolver. | |||
fec0:0:0:ffff::3. | ||||
[Note to readers: the above addresses are tentative, but the ffff | Each local DNS resolvers should be configured with one of those three | |||
is intended to be consistent with a simultaneous proposal to | addresses to enable clients to switch from one to the other if one | |||
reserve the ffff SLA for use with IANA-assigned addresses such as | fails. Host routes for each of those resolvers should be injected in | |||
these.] | the local routing system. Example methods for injecting host routes | |||
and a brief discussion of their fate sharing properties is presented | ||||
here: | ||||
Draft Stateless DNS Discovery March 2002 | 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 | ||||
may not be notified and keep announcing the route. | ||||
6. Acknowledgements | b) Running a routing protocol on the same node running the DNS | |||
resolver. | ||||
If the process running the DNS resolver dies, the routing protocol | ||||
may or may not be notified and keep annoucing the route. | ||||
The IPv6 DNS Discovery Design Team [DDDT] provided recommendations | c) Running a routing protocol within the same process running the | |||
that formed the basis of this specification. Rob Austein and the | DNS resolver. | |||
IPv6 Working Group provided valuable feedback on the mechanism. | If the DNS resolver and the routing protocol run in separated | |||
Aaron Schrader provided helpful comments as well. Robert Hinden | threads, similar concerns as above are true. | |||
edited this version of the document. | ||||
7. References | d) Having an "announcement" protocol that the DNS resolver could | |||
use to advertize the host route to the nearby router. | ||||
Details of such a protocols are out of scope of this document, but | ||||
something similar to [MLD] is possible. | ||||
[ADDRCONF] | IANA considerations for this prefix are covered in Section 6. | |||
Thomson, S., and T. Narten, "IPv6 Stateless Address | ||||
Autoconfiguration", RFC 2462, December 1998. | ||||
[ANYCAST] | 4. Site local versus global scope considerations | |||
Hagino, Jun-ichiro itojun, and K. Ettikan, "An analysis of | ||||
IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast- | ||||
analysis-00.txt, Work in progress, July 2001. | ||||
[DDDT] | The rationales for having a site local prefix are: | |||
Thaler, D., Editor, "Analysis of DNS Server Discovery | ||||
Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery- | ||||
analysis-00.txt | ||||
[DIFFSEC] | -a) Using a site local prefix will ensure that the traffic to the | |||
D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain | DNS resolver stays local to the site. This will prevent the DNS | |||
Name System (DNS)", RFC 2539, March 1999. | requests from accidentally leaking out of the site. However, the | |||
local resolver can implement a policy to forward DNS resolution of | ||||
non-local addresses to an external DNS resolver. | ||||
[DNSSEC] | -b) Reverse DNS resolution of site local addresses is only | |||
D. Eastlake, "Domain Name System Security Extensions", RFC | meaningful within the site. Thus, making sure that such queries | |||
2535, March 1999. | are first sent to a DNS resolver located within the site perimeter | |||
increase their likelyhood of success. | ||||
[DOMSEARCH] | Note: there is currently some discussions about the usefulness of | |||
B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc- | site local addresses in the IPv6 architecture. Depending on the | |||
domsearch-01.txt, December 2000. | 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. | ||||
[MDNS] | 5. Examples of use | |||
Esibov, L., Aboba, B., and D. Thaler, draft-ietf-dnsext- | ||||
mdns-03.txt, July 2001. | ||||
[TKEY] | This section presents example scenarios showing how the mechanism | |||
D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC | described in this memo can co-exist with other techniques, namely | |||
2930, September 2000. | manual configuration and DHCPv6 discovery. | |||
Draft Stateless DNS Discovery March 2002 | 5.1 Simple case, general purpose DNS resolver | |||
[TSIG] | This example shows the case of an enterprise or a cellular network | |||
Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, | that manages a full flavor general purpose DNS resolver and a large | |||
"Secret Key Transaction Authentication for DNS (TSIG)", RFC | number of nodes running DNS stub resolvers. The DNS resolver is | |||
2845, May 2000. | performing (and caching) all the recursive queries on behalf of the | |||
stub resolvers. Those stub resolvers are either manually configured | ||||
with the IPv6 address of the resolver or with one (or several) of the | ||||
well known site local unicast addresses defined in this memo. | ||||
8. Authors' Addresses | ------------------------------------------- | |||
| | | ||||
| --------------------- | | ||||
| |manually configured| | | ||||
| |DNS stub resolver | | | ||||
| --------------------- | | ||||
| ---------- | | | ||||
| |DNS |<----------- | | ||||
| |resolver|<----------- | | ||||
| ---------- | | | ||||
| --------------------- | | ||||
| |DNS stub resolver | | | ||||
| |configured with | | | ||||
| |well known address | | | ||||
| --------------------- | | ||||
| | | ||||
------------------------------------------- | ||||
Dave Thaler | (The DNS resolver is configured to listen both on | |||
Microsoft | its IPv6 address and on the well known address) | |||
One Microsoft Way | ||||
Redmond, CA 98052, USA | ||||
Email: dthaler@microsoft.com | ||||
Jun-ichiro itojun HAGINO | 5.2 DNS forwarder | |||
Research Laboratory, Internet Initiative Japan Inc. | ||||
Takebashi Yasuda Bldg., | ||||
3-13 Kanda Nishiki-cho, | ||||
Chiyoda-ku, Tokyo 101-0054, JAPAN | ||||
Email: itojun@iijlab.net | ||||
Draft Stateless DNS Discovery March 2002 | 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 | ||||
office network connected to an ISP, DNS traffic cannot be sent | ||||
directly to the ISP DNS resolver without having the ISP and all its | ||||
customers share the same definition of site. | ||||
9. Appendix A - Level 2 Compliance | In this scenario, the home/small office network is connected to the | |||
ISP router (PE) via an edge router (CPE). Prefix delegation is | ||||
performed out of band is is out of scope of this memo. | ||||
Level 2 compliance allows site administrators to have site-wide | ------------- | |||
defaults for all name resolution parameters, and optionally to | / | | |||
have subnet-specific overrides. However, it defines a new DNS | -------- -------------- / | | |||
record type to hold name resolutioin configuration information. | |ISP PE| |customer CPE| / Customer | | |||
In this way, DNS becomes self-configuring. | | |===========| |====< site | | |||
| | | | \ | | ||||
-------- -------------- \ | | ||||
\ | | ||||
------------- | ||||
9.1. DNS Server Configuration | The customer router CPE could be configured on its internal interface | |||
with one of the reserved site local addresses and listen for DNS | ||||
queries. It would be configured to use one (or several) of the well | ||||
known site local unicast addresses within the ISP's site to send its | ||||
own queries to. It would act as a DNS forwarder, forwarding queries | ||||
received on its internal interface to the ISP's DNS resolver. | ||||
A new record type, CFG, is defined, with a syntax as follows: | ------------- | |||
<owner> <class> <ttl> CFG "<attribute name>=<attribute value>" | / | | |||
---------- -------------- / | | ||||
|ISP | |customer CPE| / Customer | | ||||
|DNS |===========| DNS|====< site | | ||||
|resolver| <------|---forwarder|-----\---- | | ||||
---------- -------------- \ | | ||||
\ | | ||||
------------- | ||||
The set of attribute names is described below. This set may be | In this configuration, the CPE is acting as a multi-sited router. | |||
extended by other RFCs, but any new attributes MUST be specific to | ||||
name resolution. | ||||
The DNS server list is expressed with a string of the form | 5.3 DNS forwarder with DHCPv6 interactions | |||
"dnsservers=<address>[,<address>]*" where the attribute value is a | ||||
comma-separated list of one or more addresses (either IPv4 or | ||||
IPv6) in string literal format suitable for passing to | ||||
getaddrinfo. | ||||
The domain name to use is expressed with a string of the form | In this variant scenario, DHCPv6 could be used between the PE and CPE | |||
"domainname=<domain>" where the attribute value is the domain name | to do prefix delegation [DELEG] and DNS resolver discovery. | |||
the client should use. | ||||
The domain suffix search path is expressed with a string of the | ------------- | |||
form "searchpath=<domain>[,<domain>]*" where the attribute value | / | | |||
is a comma-separated list of domain suffixes. | -------- -------------- / | | |||
|ISP | |customer CPE| / Customer | | ||||
|DHCPv6|===========| DHCPv6|====< site | | ||||
|server| <------|------client| \ | | ||||
-------- -------------- \ | | ||||
\ | | ||||
------------- | ||||
The mDNS enabled flag is expressed with a string of the form | This example will show how DHCPv6 and well known site local unicast | |||
"mdnsenabled=<value>" where the attribute value is either "true" | addresses can be used at the same time within a site to discover the | |||
or "false". | address of the DNS forwarder. | |||
Name resolution information can be expressed as defaults for the | The customer router CPE could be configured on its internal interface | |||
entire site, as well as per-subnet overrides if desired. To | with one of the reserved site local addresses and listen for DNS | |||
express site defaults, the record owner used is a wildcard, namely | queries. It would act as a DNS forwarder, forwarding those queries to | |||
*.local.arpa. The format of per-subnet overrides is described in | the DNS resolver pointed out by the ISP in the DHCPv6 exchange. | |||
the next section. | ||||
[NOTE WELL: the use of "local.arpa" and the CFG record syntax | ------------- | |||
shown above are just placeholders until DNS experts figure out | / | | |||
what the right thing is.] | ---------- -------------- / | | |||
|ISP | |customer CPE| / Customer | | ||||
|DNS |===========| DNS|====< site | | ||||
|resolver| <------|---forwarder|-----\---- | | ||||
---------- -------------- \ | | ||||
\ | | ||||
------------- | ||||
Draft Stateless DNS Discovery March 2002 | The same CPE router could also act as a local DHCPv6 server, | |||
advertising either itself as DNS forwarder. | ||||
Each of the attributes described herein are optional, and any | ------------- | |||
combination may be used, except that only one record per | / | | |||
attributename should be present per owner (site or subnet) string. | -------- -------------- / Customer | | |||
|ISP PE| |customer CPE| / site | | ||||
| |===========|DHCPv6 |====< | | ||||
| | |server------|-----\---> | | ||||
-------- -------------- \ | | ||||
\ | | ||||
------------- | ||||
*.local.arpa IN CFG "dnsservers=fec0:0:1::1,fec0:0:2::2" | Within the site: | |||
*.local.arpa IN CFG "domainname=example.com" | ||||
*.local.arpa IN CFG "searchpath=foo.example.com, | ||||
bar.example.com,example.com" | ||||
*.local.arpa IN CFG "mdnsenabled=true" | ||||
Table 1: Example configuration | a) DHCPv6 aware clients could use DHCPv6 to obtain the address of | |||
the DNS forwarder... | ||||
The DNS server must also be assigned one of the well-known site- | ------------- | |||
local addresses, and a host route must be injected into the site's | / | | |||
routing infrastructure, e.g. using one of the methods described | ---------- -------------- / Customer | | |||
above in Section 3.1. | |ISP | |customer CPE| / site | | |||
|DNS |===========| DNS|====< | | ||||
|resolver| <------|---forwarder|-----\----DHCPv6 | | ||||
---------- -------------- \ client | | ||||
\ | | ||||
------------- | ||||
(The address of the DNS forwarder is aquired via DHCPv6.) | ||||
9.2. Host Behavior | b) other nodes may simply send their DNS request to the reserved | |||
site local addresses. | ||||
When an interface comes up, and a host determines that the | ------------- | |||
OtherConfigFlag on the interface is off, then it takes the | / | | |||
following actions. | ---------- -------------- / customer | | |||
|ISP | |customer CPE| / site | | ||||
|DNS |===========| DNS|====< | | ||||
|resolver| <------|---forwarder|-----\----non DHCPv6| | ||||
---------- -------------- \ node | | ||||
\ | | ||||
------------- | ||||
(Internal nodes use the reserved site local unicast address.) | ||||
The host constructs a DNS query for CFG records for | A variant of this scenario is the CPE can decide to pass the global | |||
"<subnet>.local.arpa.", where <subnet> is constructed from an | address of the ISP DNS resolver in the DHCPv6 exchange with the | |||
onlink prefix as follows: | internal nodes. | |||
1) Determine the onlink prefix to use. Any onlink site-local | 6. IANA considerations | |||
prefix is used, if present. Otherwise, any onlink global | ||||
prefix is used. If no other onlink prefixes are present (e.g., | ||||
if no routers are present), the link-local prefix is used as a | ||||
last resort. | ||||
2) Convert the subnet prefix to a string by taking the lower case | The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out | |||
string literal representation, with no zero compression, and | of the site local fec0::/10 prefix. | |||
replacing all colons with underscores. Table 2 below shows | ||||
some examples. This notation is used so that it uses only one | ||||
token, is unique per prefix, and is human readable. | ||||
Draft Stateless DNS Discovery March 2002 | 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 | ||||
configuration. | ||||
Prefix String | All other addresses within the fec0:0000:0000:ffff::/64 are reserved | |||
fec0:0:0:1::/64 fec0_0000_0000_0001.local.arpa | for future use and are expected to be assigned only with IESG | |||
3ffe:ffff:0:1234::/64 3ffe_ffff_0000_1234.local.arpa | approval. | |||
fe80::/64 fe80_0000_0000_0000.local.arpa | ||||
Table 2: Example queries | 7. Security Considerations | |||
Once the query is formed, the host initially sends out the query | Ensuring that queries reach a legitimate DNS server relies on the | |||
using UDP to each discovery address in turn until a reply is | security of the IPv6 routing infrastructure. The issues here are the | |||
received, or until the end of the list is reached. To avoid | same as those for protecting basic IPv6 connectivity. | |||
implosion problems when an entire site reboots such as after a | ||||
power outage, the first request should wait 3 seconds for a reply, | ||||
with the wait period doubling for each subsequent request. | ||||
Since the destination address may be an anycast address, the reply | IPsec/IKE can be used as the well-known addresses are used as unicast | |||
will necessarily come from a different address. The host must not | addresses. | |||
discard the reply simply because the source address is different. | ||||
A more detailed discussion of this issue can be found in | ||||
[ANYCAST]. | ||||
Upon receiving a response, the host parses the CFG records and | The payload can be protected using standard DNS security techniques. | |||
acts on the information as follows. | If the client can preconfigure a well known private or public key | |||
then TSIG [TSIG] can be used with the same packets presented for the | ||||
query. If this is not the case, then TSIG keys will have to be | ||||
negotiated using [TKEY]. After the client has the proper key then | ||||
the query can be performed. | ||||
If a dnsservers attribute is present, the list of server addresses | The use of site local addresses instead of global addresses will | |||
is extracted from the value. If no such attribute is present (or | ensure the DNS queries issued by host using this mechanism will not | |||
if no reply is received), an implementation-specific default list | leak out of the site. | |||
is used. For example: | ||||
o an implementation MAY use an empty list (effectively | 8. References | |||
disabling name resolution), | ||||
o a host MAY use a DNS server list containing only the anycast | [ADDRCONF] | |||
address, subject to the limitations discussed in the next | Thomson, S., and T. Narten, "IPv6 Stateless Address | |||
section, | Autoconfiguration", RFC 2462, December 1998. | |||
o a host MAY use mDNS [MDNS] only, or | [MLD] | |||
Deering, S., Fenner, W., Haberman, B., | ||||
"Multicast Listener Discovery (MLD) for IPv6", | ||||
RFC2710, October 1999. | ||||
o a host MAY use some combination of the above. | [TSIG] | |||
Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, | ||||
"Secret Key Transaction Authentication for DNS (TSIG)", | ||||
RFC2845, May 2000. | ||||
In general, the list obtained is used in the same way as if the | [TKEY] | |||
list had been obtained (or failed to be obtained) via DHCP. | D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)", | |||
RFC2930, September 2000. | ||||
If a domainname attribute is present, the domain name is extracted | [DHCPv6] | |||
Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and | ||||
Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6 | ||||
(DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), | ||||
Februray 2002. | ||||
Draft Stateless DNS Discovery March 2002 | [DELEG] | |||
Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6", | ||||
draft-troan-dhcpv6-opt-prefix-delegation-00.txt (work in progress), | ||||
February 2002. | ||||
from the value. The domain name (or lack thereof) is used in the | 9. Authors' Addresses | |||
same way as if the list had been obtained (or failed to be | ||||
obtained) via DHCP. | ||||
If the searchpath attribute is present, the search path is | Alain Durand | |||
extracted from the value. If not present, the host uses the | SUN microsystems, inc. | |||
search path it would use if no path had been obtained if DHCP were | 901 San Antonio rd UMPK 17-202 | |||
in use. | Palo Alto, CA 94303, USA. | |||
Email: Alain.Durand@sun.com | ||||
If the mdnsenabled attribute is present, the value is extracted. | Jun-ichiro itojun HAGINO | |||
If not present, mDNS is not enabled. | Research Laboratory, Internet Initiative Japan Inc. | |||
Takebashi Yasuda Bldg., | ||||
3-13 Kanda Nishiki-cho, | ||||
Chiyoda-ku, Tokyo 101-0054, JAPAN | ||||
Email: itojun@iijlab.net | ||||
Draft Stateless DNS Discovery March 2002 | Dave Thaler | |||
Microsoft | ||||
One Microsoft Way | ||||
Redmond, CA 98052, USA | ||||
Email: dthaler@microsoft.com | ||||
10. Full Copyright Statement | 10. Full Copyright Statement | |||
Copyright (C) The Internet Society (2001). All Rights Reserved. | Copyright (C) The Internet Society (2002). All Rights Reserved. | |||
This document and translations of it may be copied and furnished | This document and translations of it may be copied and furnished to | |||
to others, and derivative works that comment on or otherwise | others, and derivative works that comment on or otherwise explain it | |||
explain it or assist in its implementation may be prepared, | or assist in its implementation may be prepared, copied, published | |||
copied, published and distributed, in whole or in part, without | and distributed, in whole or in part, without restriction of any | |||
restriction of any kind, provided that the above copyright notice | kind, provided that the above copyright notice and this paragraph are | |||
and this paragraph are included on all such copies and derivative | included on all such copies and derivative works. However, this | |||
works. However, this document itself may not be modified in any | document itself may not be modified in any way, such as by removing | |||
way, such as by removing the copyright notice or references to the | the copyright notice or references to the Internet Society or other | |||
Internet Society or other Internet organizations, except as needed | Internet organizations, except as needed for the purpose of | |||
for the purpose of developing Internet standards in which case the | developing Internet standards in which case the procedures for | |||
procedures for copyrights defined in the Internet languages other | copyrights defined in the Internet languages other than English. | |||
than English. | ||||
The limited permissions granted above are perpetual and will not | The limited permissions granted above are perpetual and will not be | |||
be revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
This document and the information contained herein is provided on | This document and the information contained herein is provided on an | |||
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |