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/