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

        Well known site local unicast addresses for DNS Discovery
              <draft-ietf-ipv6-dns-discovery-04.txt> 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-

   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


   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.

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

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

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


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

   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

   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

      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
      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:


   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

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

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

     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.

     Thaler, D., Editor, "Analysis of DNS Server Discovery
     Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery-

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

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

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

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

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

Draft                 Stateless ISP's DNS Discovery           March 2002

     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
One Microsoft Way
Redmond, CA 98052, USA

Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku, Tokyo 101-0054, JAPAN

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

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
*  The format of per-subnet overrides is described in
the next section.

[NOTE WELL: between the use of "" 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.

*   IN   CFG   "dnsservers=fec0:0:1::1,fec0:0:2::2"
*   IN   CFG   ""
*   IN   CFG   ",
*   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>", 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
-----------------          --------------------------------------

                     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

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

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

   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

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

   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.

   leak out of the site.

8.  References

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

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

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

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

        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.

        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.

   Jun-ichiro itojun HAGINO
   Research Laboratory, Internet Initiative Japan Inc.
   Takebashi Yasuda Bldg.,
   3-13 Kanda Nishiki-cho,
   Chiyoda-ku, Tokyo 101-0054, JAPAN

   Dave Thaler
   One Microsoft Way
   Redmond, CA 98052, USA

10.  Full Copyright Statement

Copyright (C) The Internet Society (2001). (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.

   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