--- 1/draft-ietf-ipv6-dns-discovery-05.txt 2006-02-05 00:02:17.000000000 +0100 +++ 2/draft-ietf-ipv6-dns-discovery-06.txt 2006-02-05 00:02:17.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group Alain Durand INTERNET-DRAFT SUN Microsystems, inc. -June 14, 2002 Jun-ichiro itojun Hagino -Expires December 2002 IIJ Research Laboratory +August 21, 2002 Jun-ichiro itojun Hagino +Expires February 2002 IIJ Research Laboratory Dave Thaler Microsoft Well known site local unicast addresses for DNS resolver - + - Status of this Memo + Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet Drafts are valid for a maximum of six months and may be @@ -23,23 +23,25 @@ is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This documents specifies a method for nodes to find a DNS resolver 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. 1. Introduction RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or more IPv6 address and default routes. 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 @@ -79,83 +81,95 @@ 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 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 mechanism described here is to be used as a last resort, when no - other configuration information is available. + The mechanism described here is to be used as a last resort, in the + 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 - 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. + Implementing only the mechanism described in this memo may end up + causing some interoperability problems when operating in networks + where no DNS resolver is configured with the well known addresses. + 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 - addresses as DNS resolver. +3. Reserved prefix and addresses - 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 - fails. Host routes for each of those resolvers should be injected in - the local routing system. Example methods for injecting host routes - and a brief discussion of their fate sharing properties is presented - here: + fails. + + A solution to enable clients to reach the DNS resolvers is to inject + 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. If the node running the DNS resolver goes down, the router may or may not be notified and keep announcing the route. 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. c) Running a routing protocol within the same process running the DNS resolver. If the DNS resolver and the routing protocol run in separated threads, similar concerns as above are true. 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. + 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. + + 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. 4. Site local versus global scope considerations The rationales for having a site local prefix are: -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 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. -b) Reverse DNS resolution of site local addresses is only meaningful within the site. Thus, making sure that such queries are first sent to a DNS resolver located within the site perimeter 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 This section presents example scenarios showing how the mechanism described in this memo can co-exist with other techniques, namely manual configuration and DHCPv6 discovery. 5.1 Simple case, general purpose DNS resolver This example shows the case of an enterprise or a cellular network that manages a full flavor general purpose DNS resolver and a large @@ -188,22 +202,21 @@ 5.2 DNS forwarder 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. 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. + ISP router (PE) via an edge router (CPE). ------------- / | -------- -------------- / | |ISP PE| |customer CPE| / Customer | | |===========| |====< site | | | | | \ | -------- -------------- \ | \ | ------------- @@ -222,83 +235,82 @@ |DNS |===========| DNS|====< site | |resolver| <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- In this configuration, the CPE is acting as a multi-sited router. 5.3 DNS forwarder with DHCPv6 interactions - In this variant scenario, DHCPv6 could be used between the PE and CPE - to do prefix delegation [DELEG] and DNS resolver discovery. + In this variant scenario, DHCPv6 is be used between the PE and CPE to + do prefix delegation [DELEG] and DNS resolver discovery. ------------- / | -------- -------------- / | |ISP | |customer CPE| / Customer | |DHCPv6|===========| DHCPv6|====< site | |server| <------|------client| \ | -------- -------------- \ | \ | ------------- 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 - address of the DNS forwarder. + addresses cooperate to enable the internal nodes to access DNS. - 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 act as a DNS forwarder, forwarding those queries to - the DNS resolver pointed out by the ISP in the DHCPv6 exchange. + The customer router CPE is configured on its internal interface with + one of the reserved site local addresses and listen for DNS queries. + It would act as a DNS forwarder, as in 5.2, forwarding those queries + to the DNS resolver pointed out by the ISP in the DHCPv6 exchange. ------------- / | ---------- -------------- / | |ISP | |customer CPE| / Customer | |DNS |===========| DNS|====< site | |resolver| <------|---forwarder|-----\---- | ---------- -------------- \ | \ | ------------- - The same CPE router could also act as a local DHCPv6 server, - advertising either itself as DNS forwarder. + The same CPE router could also implement a local DHCPv6 server and + advertises itself as DNS forwarder. ------------- / | -------- -------------- / Customer | |ISP PE| |customer CPE| / site | | |===========|DHCPv6 |====< | | | |server------|-----\---> | -------- -------------- \ | \ | ------------- Within the site: - a) DHCPv6 aware clients could use DHCPv6 to obtain the address of - the DNS forwarder... + a) DHCPv6 aware clients use DHCPv6 to obtain the address of the + DNS forwarder... ------------- / | ---------- -------------- / Customer | |ISP | |customer CPE| / site | |DNS |===========| DNS|====< | |resolver| <------|---forwarder|-----\----DHCPv6 | ---------- -------------- \ client | \ | ------------- (The address of the DNS forwarder is aquired via DHCPv6.) - b) other nodes may simply send their DNS request to the reserved - site local addresses. + b) other nodes simply send their DNS request to the reserved site + local addresses. ------------- / | ---------- -------------- / customer | |ISP | |customer CPE| / site | |DNS |===========| DNS|====< | |resolver| <------|---forwarder|-----\----non DHCPv6| ---------- -------------- \ node | \ | ------------- @@ -307,21 +319,21 @@ 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 internal nodes. 6. IANA considerations The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out of the site local fec0::/10 prefix. 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. All other addresses within the fec0:0000:0000:ffff::/64 are reserved for future use and are expected to be assigned only with IESG approval. 7. Security Considerations Ensuring that queries reach a legitimate DNS server relies on the security of the IPv6 routing infrastructure. The issues here are the