--- 1/draft-ietf-ipv6-dns-discovery-04.txt 2006-02-05 00:02:16.000000000 +0100 +++ 2/draft-ietf-ipv6-dns-discovery-05.txt 2006-02-05 00:02:16.000000000 +0100 @@ -1,474 +1,420 @@ +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 -INTERNET-DRAFT Microsoft -March 1, 2002 Jun-ichiro itojun Hagino -Expires August 2002 IIJ Research Laboratory - - IPv6 Stateless DNS Discovery - + Well known site local unicast addresses for DNS resolver + 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 -updated, replaced, or obsoleted by other documents at any time. -It is inappropriate to use Internet Drafts as reference material -or to cite them other than as a "work in progress". + updated, replaced, or obsoleted by other documents at any time. It + 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 document specifies the steps a host takes in deciding how to -autoconfigure the addresses of DNS Servers required for name -resolution in IP version 6. The autoconfiguration process -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. + 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. -Draft Stateless DNS Discovery March 2002 - 1. Introduction -RFC 2462 [ADDRCONF] specifies "OtherConfigFlag" as a per-interface -variable, which is set from the value of the "O" ("Other stateful -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 + RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or + more IPv6 address and default routes. - 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 -addresses listed above. The search path is not discovered, but is -generated from the host's domain name(s) as is currently common -practice. If desired, a per-interface domain name can be obtained -by sending a query (with the Recursion Desired (RD) bit set), -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. + The intended usage scenario for this proposal is a home or enterprise + network where IPv6 nodes are plugged/unplugged with minimum + management and use local resources available on the network to + autoconfigure. This proposal is also usefull in cellular networks + where all moble devices are included within the same site. -4. Security Considerations +2. Pre-configuration vs discovery -Ensuring that queries reach a legitimate DNS server relies on the -security of the IPv6 routing infrastructure. The issues here are -the same as those for protecting basic IPv6 connectivity. + Some of the discussions in the past around DNS server discovery have + been trying to characterize the solution space into stateless versus + 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 -unicast addresses. + 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 payload can be protected 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. + The mechanism described here is to be used as a last resort, when no + other configuration information is available. -5. IANA Considerations +3. Reserved Prefix and addresses -The IANA should assign the following site-local IPv6 addresses to -be used as well-known addresses assigned to DNS servers: + 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. - fec0:0:0:ffff::1 - fec0:0:0:ffff::2 - fec0:0:0:ffff::3. + IPv6 nodes will be pre-configured (hard coded) with those three IPv6 + addresses as DNS resolver. -[Note to readers: the above addresses are tentative, but the ffff -is intended to be consistent with a simultaneous proposal to -reserve the ffff SLA for use with IANA-assigned addresses such as -these.] + Each 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: -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 -that formed the basis of this specification. Rob Austein and the -IPv6 Working Group provided valuable feedback on the mechanism. -Aaron Schrader provided helpful comments as well. Robert Hinden -edited this version of the document. + 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. -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] - Thomson, S., and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. + IANA considerations for this prefix are covered in Section 6. -[ANYCAST] - 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. +4. Site local versus global scope considerations -[DDDT] - Thaler, D., Editor, "Analysis of DNS Server Discovery - Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery- - analysis-00.txt + The rationales for having a site local prefix are: -[DIFFSEC] - D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain - Name System (DNS)", RFC 2539, March 1999. + -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. -[DNSSEC] - D. Eastlake, "Domain Name System Security Extensions", RFC - 2535, March 1999. + -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. -[DOMSEARCH] - B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc- - domsearch-01.txt, December 2000. + 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. -[MDNS] - Esibov, L., Aboba, B., and D. Thaler, draft-ietf-dnsext- - mdns-03.txt, July 2001. +5. Examples of use -[TKEY] - D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC - 2930, September 2000. + 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. -Draft Stateless DNS Discovery March 2002 +5.1 Simple case, general purpose DNS resolver -[TSIG] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. + This example shows the case of an enterprise or a cellular network + that manages a full flavor general purpose DNS resolver and a large + number of nodes running DNS stub resolvers. The DNS resolver is + 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 -Microsoft -One Microsoft Way -Redmond, CA 98052, USA -Email: dthaler@microsoft.com + (The DNS resolver is configured to listen both on + its IPv6 address and on the well known address) -Jun-ichiro itojun HAGINO -Research Laboratory, Internet Initiative Japan Inc. -Takebashi Yasuda Bldg., -3-13 Kanda Nishiki-cho, -Chiyoda-ku, Tokyo 101-0054, JAPAN -Email: itojun@iijlab.net +5.2 DNS forwarder -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. -In this way, DNS becomes self-configuring. + ------------- + / | + -------- -------------- / | + |ISP PE| |customer CPE| / Customer | + | |===========| |====< 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: - CFG "=" + ------------- + / | + ---------- -------------- / | + |ISP | |customer CPE| / Customer | + |DNS |===========| DNS|====< site | + |resolver| <------|---forwarder|-----\---- | + ---------- -------------- \ | + \ | + ------------- -The set of attribute names is described below. This set may be -extended by other RFCs, but any new attributes MUST be specific to -name resolution. + In this configuration, the CPE is acting as a multi-sited router. -The DNS server list is expressed with a string of the form -"dnsservers=
[,
]*" 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. +5.3 DNS forwarder with DHCPv6 interactions -The domain name to use is expressed with a string of the form -"domainname=" where the attribute value is the domain name -the client should use. + In this variant scenario, DHCPv6 could be used between the PE and CPE + to do prefix delegation [DELEG] and DNS resolver discovery. -The domain suffix search path is expressed with a string of the -form "searchpath=[,]*" 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 -"mdnsenabled=" where the attribute value is either "true" -or "false". + 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. -Name resolution information can be expressed as defaults for the -entire site, as well as per-subnet overrides if desired. To -express site defaults, the record owner used is a wildcard, namely -*.local.arpa. The format of per-subnet overrides is described in -the next section. + 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. -[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" -*.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" + Within the site: - 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 -above in Section 3.1. + ------------- + / | + ---------- -------------- / Customer | + |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 -".local.arpa.", where is constructed from an -onlink prefix as follows: + 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. -1) Determine the onlink prefix to use. Any onlink site-local - 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. +6. IANA considerations -2) Convert the subnet prefix to a string by taking the lower case - string literal representation, with no zero compression, and - 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. + The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out + of the site local fec0::/10 prefix. -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 ------------------ -------------------------------------- -fec0:0:0:1::/64 fec0_0000_0000_0001.local.arpa -3ffe:ffff:0:1234::/64 3ffe_ffff_0000_1234.local.arpa -fe80::/64 fe80_0000_0000_0000.local.arpa + 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. - Table 2: Example queries +7. Security Considerations -Once the query is formed, the host initially sends out the query -using UDP to each discovery address in turn until a reply is -received, or until the end of the list is reached. To avoid -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. + Ensuring that queries reach a legitimate DNS server relies on the + security of the IPv6 routing infrastructure. The issues here are the + same as those for protecting basic IPv6 connectivity. -Since the destination address may be an anycast address, the reply -will necessarily come from a different address. The host must not -discard the reply simply because the source address is different. -A more detailed discussion of this issue can be found in -[ANYCAST]. + IPsec/IKE can be used as the well-known addresses are used as unicast + addresses. -Upon receiving a response, the host parses the CFG records and -acts on the information as follows. + The payload can be protected using standard DNS security techniques. + 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 -is extracted from the value. If no such attribute is present (or -if no reply is received), an implementation-specific default list -is used. For example: + The use of site local addresses instead of global addresses will + ensure the DNS queries issued by host using this mechanism will not + leak out of the site. -o an implementation MAY use an empty list (effectively - disabling name resolution), +8. References -o a host MAY use a DNS server list containing only the anycast - address, subject to the limitations discussed in the next - section, + [ADDRCONF] + Thomson, S., and T. Narten, "IPv6 Stateless Address + 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 -list had been obtained (or failed to be obtained) via DHCP. + [TKEY] + 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 -same way as if the list had been obtained (or failed to be -obtained) via DHCP. +9. Authors' Addresses -If the searchpath attribute is present, the search path is -extracted from the value. If not present, the host uses the -search path it would use if no path had been obtained if DHCP were -in use. + Alain Durand + SUN microsystems, inc. + 901 San Antonio rd UMPK 17-202 + Palo Alto, CA 94303, USA. + Email: Alain.Durand@sun.com -If the mdnsenabled attribute is present, the value is extracted. -If not present, mDNS is not enabled. + Jun-ichiro itojun HAGINO + 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 -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 -to others, and derivative works that comment on or otherwise -explain it or assist in its implementation may be prepared, -copied, published and distributed, in whole or in part, without -restriction of any kind, provided that the above copyright notice -and this paragraph are included on all such copies and derivative -works. However, this document itself may not be modified in any -way, such as by removing the copyright notice or references to the -Internet Society or other Internet organizations, except as needed -for the purpose of developing Internet standards in which case the -procedures for copyrights defined in the Internet languages other -than English. + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet languages other than English. -The limited permissions granted above are perpetual and will not -be revoked by the Internet Society or its successors or assigns. + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. -This document and the information contained herein is provided on -an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET -ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF -THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED -WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.