Commit dc3fe367 authored by Mark Andrews's avatar Mark Andrews
Browse files

new draft

parent e9b85f03
This diff is collapsed.
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
......@@ -9,11 +9,11 @@ Expires December 2002 IIJ Research Laboratory
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
all provisions of Section 10 of RFC2026.
......@@ -37,16 +37,18 @@ 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
1. Introduction
RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
more IPv6 address and default routes.
......@@ -99,29 +101,41 @@ Copyright Notice
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.
Note to implementors:
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.
3. Reserved Prefix and addresses
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.
IPv6 nodes will be pre-configured (hard coded) with those three IPv6
addresses as DNS resolver.
Each local DNS resolvers should be configured with one of those three
3. Reserved prefix and addresses
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
......@@ -138,10 +152,16 @@ Copyright Notice
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.
......@@ -162,13 +182,6 @@ Copyright Notice
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
......@@ -219,8 +232,7 @@ Copyright Notice
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).
-------------
/ |
......@@ -255,8 +267,8 @@ Copyright Notice
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.
-------------
/ |
......@@ -269,13 +281,12 @@ Copyright Notice
-------------
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.
-------------
/ |
......@@ -288,8 +299,8 @@ Copyright Notice
-------------
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.
-------------
/ |
......@@ -305,8 +316,8 @@ Copyright Notice
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...
-------------
/ |
......@@ -320,8 +331,8 @@ Copyright Notice
(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.
-------------
/ |
......@@ -347,7 +358,7 @@ Copyright Notice
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
......@@ -518,16 +529,6 @@ Copyright (C) The Internet Society (2002). All Rights Reserved.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment