wdiff draft-ietf-ipv6-dns-discovery-04.txt draft-ietf-ipv6-dns-discovery-05.txt

Network Working Group Dave Thaler Alain Durand
INTERNET-DRAFT Microsoft
March 1, SUN Microsystems, inc.
June 14, 2002 Jun-ichiro itojun Hagino
Expires August December 2002 IIJ Research Laboratory

IPv6 Stateless
Dave Thaler
Microsoft

Well known site local unicast addresses for DNS Discovery
<draft-ietf-ipv6-dns-discovery-04.txt> resolver
<draft-ietf-ipv6-dns-discovery-05.txt>

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".

To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.

Abstract

This document documents specifies the steps a host takes in deciding how method for nodes to
autoconfigure the addresses of find a DNS Servers required for name
resolution resolver
with minimum configuration 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, network and the domain name of the host via without running a stateless mechanism are

Draft Stateless DNS Discovery March 2002

included in an appendix for further study. The details of
autoconfiguration using the stateful
discovery protocol are specified
elsewhere. on the nodes.

Draft Stateless DNS Discovery March 2002

1. Introduction

RFC 2462 [ADDRCONF] specifies "OtherConfigFlag" as provides 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 way to
name resolution is obtained using the stateful autoconfiguration
mechanism. autoconfigure nodes with one or
more IPv6 address and default routes.

However, when OtherConfigFlag is not set, it does not
describe how for a node to obtain be fully operational on a network, many other
parameters are needed, such information. This is as the purpose address of
this document.

For a host to effectively resolve names of other hosts, and
potentially allow resolution of its DNS resolver, mail
relays, web proxies, etc. Except for name to be performed, resolution, all the
following parameters other
services are typically required:

o One usually described using names, not addresses, such as
smtp.myisp.net 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 webcache.myisp.net. For obvious bootstrapping
reasons, a device
desiring node needs to perform name resolution.

o A per-interface domain name of be configured with the host itself, and is
equivalent to IP address (and not
the Domain Name option in [DHCP]. This can be
used when Multicast name) of a DNS resolver. As IPv6 addresses look much more
complex than IPv4 ones, there is enabled, and the host responds some incentive to
queries for its own name, make this
configuration as well automatic and simple as when DNS Dynamic Update is
enabled. Depending on the implementation, the per-interface
domain name may or may not possible.

Although it would be the same thing as the primary
domain name of the host.

o Search path. It desirable to have all configuration parameters
configured/discovered automatically, it is currently common practice for in IPv4
today to ask the search
path user to be computed do manual configuration for some of them by
entering server names in 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 form. So, 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 solution that
will allow for automatic configuration of the
requirements and solution space, which was used DNS resolver is seen as
an important step forward in the basis autoconfiguration story.

The intended usage scenario for this document. One result of this analysis was that there proposal is a
spectrum of configuration/discovery mechanisms. At one end, a
single protocol is used home or enterprise
network where IPv6 nodes are plugged/unplugged with minimum
management and use local resources available on the network to configure/discovery all types of
information.
autoconfigure. This style works well proposal is also usefull in an administered environment cellular networks
where a network administrator wants to have a central point all moble devices are included within the same site.

2. Pre-configuration vs discovery

Some of

Draft Stateless the discussions in the past around DNS Discovery March 2002

control, and apply policies, etc. At server discovery have
been trying to characterize the other end, each protocol solution space into stateless versus
stateful or server-oriented versus severless. It is self-configuring, rather than depending on not absolutely
clear how much state if any other protocol
or server. This style provides optimal fate sharing, needs to be kept to perform DNS server
discovery, and, although the semantic differences between a router
and works a server are well in zero-configuration environments such as adhoc networks and
simple networks without network administrator staff. The former
mechanism is used with understood from a conceptual perspective, the "Other stateful configuration" flag is
used, and this draft provides
current implementations tend to blur the benefits (and limitations) of 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 latter approach when "Other stateful configuration" service.

One avenue is not
set.

Note: This document only includes to ask the IPv6 node to participate in its body a solution for
obtaining discovery
protocol, such as SLP or DHCP, learn 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 server and
send packets to this server. Another one is to pre-configure (hard-
code) a separate
document in local scope address on 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 node and let it send packets
directly to different servers. The use of the
addresses as anycast addresses this address, 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 underlying assumption that the site's
routing tables. system will forward them to the right place. This document proposes
explores this later avenue of pre-configuration that these three addresses
be:

fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3

This list does not require
participation of three addresses may the end node in the DNS resolver discovery
mechanism.

The mechanism described here is to be hardcoded into used as a host.

Furthermore, we define two levels of functionality. Level 1 is
defined below. Level 2 last resort, when no
other configuration information is described in Appendix A available.

3. Reserved Prefix and addresses

The basic idea of this proposal is for
further study.

Draft Stateless DNS Discovery March 2002

3. Level 1 Compliance

Level 1 compliance entails using the to reserve a well known IPv6 site
local prefix and three well known IPv6 addresses above for
actual name resolution. It provides only rudimentary
functionality. In particular, it does not provide the ability to DNS resolvers
and then have separate configuration for hosts on different subnets, nor to
provide hosts with a domain name other than one for which the routing system forward the DNS
server is authoritative.

3.1. request to those DNS Server Configuration

Level 1 functionality requires no
resolvers.

IPv6 nodes will be pre-configured (hard coded) with those three IPv6
addresses as DNS server configuration other
than assigning resolver.

Each local DNS resolvers should be configured with one of the well-known those three
addresses to enable clients to switch from one of to the
server's interfaces. A host route must then other if one
fails. Host routes for each of those resolvers should be injected into in
the local routing domain, e.g., system. Example methods for injecting host routes
and a brief discussion of their fate sharing properties is presented
here:

a) Manual injection of routes by configuring a static host route router on the
server's router, and redistributing it into same subnet.
If the intra-domain
routing protocol.

A host route must then be injected into node running the site's routing
infrastructure. Route injection can be done via any of several
methods, including but not limited to:

a) Run DNS resolver goes down, the server on a router, router may or
may not be notified and configure it to inject keep announcing the host route.

b) Run Running 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 node running the router(s) and DNS
resolver.
If the server(s) on process running the link. However, a server does not need to participate fully
in DNS resolver dies, the routing protocol, it only needs to protocol
may or may not be able to inject
routes. notified and keep annoucing the route.

c) Run multiple servers on Running a routing protocol within the same link(s), and configure their
local router(s) to inject host routes for process running the well-known
address into
DNS resolver.
If the DNS resolver and the site's routing infrastructure. Running
multiple servers on protocol run in separated
threads, similar concerns as above are true.

d) Having an "announcement" protocol that the same link provides robustness DNS resolver could
use to advertize the
failure of a server, while routing provides robustness host route to the
loss nearby router.
Details of routers and other links. There may still be some
failures, however, such as a unidirectional failure of the
router's interface, which protocols are not handled by out of scope of this option.

d) Modify document, but
something similar to [MLD] is possible.

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 routers on traffic to the link
DNS resolver stays local to periodically solicit (using
Neighbor Discovery) the well-known address, and inject site. This will prevent the

Draft Stateless DNS Discovery March 2002

host route based on whether
requests from accidentally leaking out of the site. However, the
local resolver can implement a reply is received.

3.2. Host Behavior

The host sets its policy to forward DNS server list equal resolution of
non-local addresses to the set an external DNS resolver.

-b) Reverse DNS resolution of three site local addresses listed above. The search path is not discovered, but is
generated from only
meaningful within the host's domain name(s) as 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 common
practice. 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 desired, a per-interface domain name can global prefix was chosen for this mechanism, concerns raised in
a) could be obtained
by sending a query (with the Recursion Desired (RD) bit set),
doing addressed using a reverse lookup for simple access list on the well-known site-local IPv6
destination address, site exit
routers and extracting the domain name from the NS
record concerns raised in b) would disappear.

5. Examples of use

This section presents example scenarios showing how the reply.

4. Security Considerations

Ensuring 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 queries reach manages a legitimate full flavor general purpose DNS server relies on resolver and a large
number of nodes running DNS stub resolvers. The DNS resolver is
performing (and caching) all the
security recursive queries on behalf of the IPv6 routing infrastructure. The issues here
stub resolvers. Those stub resolvers are either manually configured
with the same as those for protecting basic IPv6 connectivity.

IPsec/IKE can be used when address of the well-known addresses are used as
unicast addresses.

The payload can be protected as follows. If resolver or with one (or several) of the client can
preconfigure a
well known private or public key then TSIG [TSIG]
can be used site local unicast addresses defined in this memo.

-------------------------------------------
| |
| --------------------- |
| |manually configured| |
| |DNS stub resolver | |
| --------------------- |
| ---------- | |
| |DNS |<----------- |
| |resolver|<----------- |
| ---------- | |
| --------------------- |
| |DNS stub resolver | |
| |configured with | |
| |well known address | |
| --------------------- |
| |
-------------------------------------------

(The DNS resolver is configured to listen both on
its IPv6 address and on the same packets presented well known address)

5.2 DNS forwarder

A drawback of the choice of site local scope for the query. If
this reserved
addresses for DNS resolver is not that, in the case, then TSIG keys will have case of a home/small
office network connected to an ISP, DNS traffic cannot be negotiated
using [TKEY]. After sent
directly to the client has ISP DNS resolver without having the proper key then ISP and all its
customers share the query
can be performed.

5. IANA Considerations

The IANA should assign same definition of site.

In this scenario, the following site-local IPv6 addresses 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 PE| |customer CPE| / Customer |
| |===========| |====< site |
| | | | \ |
-------- -------------- \ |
\ |
-------------

The customer router CPE could be used as well-known configured on its internal interface
with one of the reserved site local addresses assigned to and listen for DNS servers:

fec0:0:0:ffff::1
fec0:0:0:ffff::2
fec0:0:0:ffff::3.

[Note
queries. It would be configured to readers: use one (or several) of the above well
known site local unicast addresses are tentative, but within the ffff
is intended ISP's site to be consistent with send its
own queries to. It would act as a simultaneous proposal DNS forwarder, forwarding queries
received on its internal interface to
reserve the ffff SLA for use with IANA-assigned addresses such as
these.]

Draft Stateless DNS Discovery March 2002

6. Acknowledgements

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.

7. References

[ADDRCONF]
Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.

[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.

[DDDT]
Thaler, D., Editor, "Analysis of DNS Server Discovery
Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery-
analysis-00.txt

[DIFFSEC]
D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", RFC 2539, March 1999.

[DNSSEC]
D. Eastlake, "Domain Name System Security Extensions", RFC
2535, March 1999.

[DOMSEARCH]
B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc-
domsearch-01.txt, December 2000.

[MDNS]
Esibov, L., Aboba, B., and D. Thaler, draft-ietf-dnsext-
mdns-03.txt, July 2001.

[TKEY]
D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)" RFC
2930, September 2000.

Draft Stateless ISP's DNS Discovery March 2002

[TSIG]
Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.

8. Authors' Addresses

Dave Thaler
Microsoft
One Microsoft Way
Redmond, CA 98052, USA
Email: dthaler@microsoft.com

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

9. Appendix A - Level 2 Compliance

Level 2 compliance allows resolver.

-------------
/ |
---------- -------------- / |
|ISP | |customer CPE| / Customer |
|DNS |===========| DNS|====< 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. |
|resolver| <------|---forwarder|-----\---- |
---------- -------------- \ |
\ |
-------------

In this way, DNS becomes self-configuring.

9.1. DNS Server Configuration

A new record type, CFG, is defined, with a syntax as follows:
<owner> <class> <ttl> CFG "<attribute name>=<attribute value>"

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.

The DNS server list is expressed with a string of configuration, the form
"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
"domainname=<domain>" where the attribute value is the domain name
the client should use.

The domain suffix search path is expressed with a string of the
form "searchpath=<domain>[,<domain>]*" where the attribute value CPE is acting as a comma-separated list of domain suffixes.

The mDNS enabled flag is expressed multi-sited router.

5.3 DNS forwarder with a string of the form
"mdnsenabled=<value>" where the attribute value is either "true"
or "false".

Name resolution information can DHCPv6 interactions

In this variant scenario, DHCPv6 could 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.

[NOTE WELL: between the use of "local.arpa" PE and the CFG record syntax
shown above are just placeholders until DNS experts figure out
what the right thing is.]

Draft Stateless DNS Discovery March 2002

Each of the attributes described herein are optional, CPE
to do prefix delegation [DELEG] and any
combination may be used, except that only one record per
attributename should be present per owner (site or subnet) string.

*.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"

Table 1: Example configuration

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.

9.2. Host Behavior

When an interface comes up, resolver discovery.

-------------
/ |
-------- -------------- / |
|ISP | |customer CPE| / Customer |
|DHCPv6|===========| DHCPv6|====< site |
|server| <------|------client| \ |
-------- -------------- \ |
\ |
-------------

This example will show how DHCPv6 and a host determines that the
OtherConfigFlag on the interface is off, then it takes the
following actions.

The host constructs a DNS query for CFG records for
"<subnet>.local.arpa.", where <subnet> is constructed from an
onlink prefix as follows:

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 well known site local unicast
addresses can be used as a
last resort.

2) Convert at the subnet prefix to same time within a string by taking site to discover the lower case
string literal representation, with no zero compression, and
replacing all colons
address of the DNS forwarder.

The customer router CPE could be configured on its internal interface
with underscores. Table 2 below shows
some examples. This notation is used so that it uses only one
token, is unique per prefix, of the reserved site local addresses and is human readable.

Draft Stateless listen for DNS Discovery March 2002

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

Table 2: Example
queries. It would act as a DNS forwarder, forwarding those queries

Once the query is formed, to
the host initially sends DNS resolver pointed out by the query
using UDP to each discovery address ISP in turn until a reply is
received, or until the end of the list is reached. To avoid
implosion problems when an entire DHCPv6 exchange.

-------------
/ |
---------- -------------- / |
|ISP | |customer CPE| / Customer |
|DNS |===========| DNS|====< site reboots such |
|resolver| <------|---forwarder|-----\---- |
---------- -------------- \ |
\ |
-------------

The same CPE router could also act as after a
power outage, the first request should wait 3 seconds for a reply,
with local DHCPv6 server,
advertising either itself as DNS forwarder.

-------------
/ |
-------- -------------- / Customer |
|ISP PE| |customer CPE| / site |
| |===========|DHCPv6 |====< |
| | |server------|-----\---> |
-------- -------------- \ |
\ |
-------------

Within the wait period doubling for each subsequent request.

Since site:

a) DHCPv6 aware clients could use DHCPv6 to obtain the destination address may be an anycast address, of
the reply
will necessarily come from a different address. The host must not
discard DNS forwarder...

-------------
/ |
---------- -------------- / Customer |
|ISP | |customer CPE| / site |
|DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----DHCPv6 |
---------- -------------- \ client |
\ |
-------------
(The address of the reply DNS forwarder is aquired via DHCPv6.)

b) other nodes may simply because send their DNS request to the source address is different. reserved
site local addresses.

-------------
/ |
---------- -------------- / customer |
|ISP | |customer CPE| / site |
|DNS |===========| DNS|====< |
|resolver| <------|---forwarder|-----\----non DHCPv6|
---------- -------------- \ node |
\ |
-------------
(Internal nodes use the reserved site local unicast address.)

A more detailed discussion variant of this issue can be found in
[ANYCAST].

Upon receiving a response, the host parses the CFG records and
acts on the information as follows.

If a dnsservers attribute scenario is present, the list CPE can decide to pass the global
address 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:

o an implementation MAY use an empty list (effectively
disabling name resolution),

o a host MAY use a ISP DNS server list containing only the anycast
address, subject to the limitations discussed resolver in the next
section,

o a host MAY use mDNS [MDNS] only, or

o a host MAY use some combination of the above.

In general, DHCPv6 exchange with the list obtained
internal nodes.

6. IANA considerations

The site local prefix fec0:0000:0000:ffff::/64 is used in to be reserved out
of the same way as if 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
configuration.

All other addresses within the
list had been obtained (or failed fec0:0000:0000:ffff::/64 are reserved
for future use and are expected to be obtained) via DHCP.

If assigned only with IESG
approval.

7. Security Considerations

Ensuring that queries reach a domainname attribute is present, the domain name is extracted

Draft Stateless legitimate DNS Discovery March 2002

from server relies on the value.
security of the IPv6 routing infrastructure. The domain name (or lack thereof) is used in issues here are the
same way as if those for protecting basic IPv6 connectivity.

IPsec/IKE can be used as the list had been obtained (or failed to well-known addresses are used as unicast
addresses.

The payload can be
obtained) via DHCP. protected using standard DNS security techniques.
If the searchpath attribute is present, client can preconfigure a well known private or public key
then TSIG [TSIG] can be used with the search path is
extracted from same packets presented for the value.
query. If this is not present, the host uses case, then TSIG keys will have to be
negotiated using [TKEY]. After the
search path it would use if no path had been obtained if DHCP were
in use.

If client has the mdnsenabled attribute is present, proper key then
the value is extracted.
If not present, mDNS is query can be performed.

The use of site local addresses instead of global addresses will
ensure the DNS queries issued by host using this mechanism will not enabled.

Draft
leak out of the site.

8. References

[ADDRCONF]
Thomson, S., and T. Narten, "IPv6 Stateless DNS Address
Autoconfiguration", RFC 2462, December 1998.

[MLD]
Deering, S., Fenner, W., Haberman, B.,
"Multicast Listener Discovery March 2002 (MLD) for IPv6",
RFC2710, October 1999.

[TSIG]
Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC2845, May 2000.

[TKEY]
D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
RFC2930, September 2000.

[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.

[DELEG]
Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
draft-troan-dhcpv6-opt-prefix-delegation-00.txt (work in progress),
February 2002.

9. Authors' Addresses

Alain Durand
SUN microsystems, inc.
901 San Antonio rd UMPK 17-202
Palo Alto, CA 94303, USA.
Email: Alain.Durand@sun.com

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

Dave Thaler
Microsoft
One Microsoft Way
Redmond, CA 98052, USA
Email: dthaler@microsoft.com

10. Full Copyright Statement

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.

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.